SOC 2 Basics for SaaS Startups Working With Offshore Developers

SOC 2 belongs to the AICPA's System and Organization Controls suite, a set of assurance services that CPAs provide on the controls of service organizations. Three points trip founders up:

• It is a report, not a certificate. A CPA firm examines your system description and controls and issues an opinion. There is no pass badge, and customers read the report, including any exceptions.
• You choose the scope. The 2017 Trust Services Criteria, with points of focus revised in 2022, cover five categories: security, availability, processing integrity, confidentiality and privacy. Many startups begin with security and add categories when customers ask for them.
• The auditor must be a licensed CPA firm. The AICPA says it is looking into anonymously published allegations about a compliance vendor that offers SOC services, and that it assists regulators, including referrals to state boards of accountancy, over unlicensed firms. Before you sign, confirm the firm's license and peer review status.

A Type 1 report looks at whether your controls are suitably designed as of a single date. A Type 2 report also tests whether they operated effectively over a period, commonly somewhere from three to 12 months. Enterprise buyers usually want Type 2, because it shows the controls working in practice rather than on paper.

A common path: reach readiness, get a Type 1 to answer near-term security reviews, then run the observation period for a Type 2. Large providers renew on a cycle; AWS, for example, publishes its SOC 2 report twice a year, each covering the previous 12 months.

Your auditor will look at how you control anyone who can touch code, infrastructure or customer data. An offshore development partner shows up in two places.

As a vendor. You need evidence of vendor management: due diligence before onboarding, a contract with security and confidentiality obligations, and periodic review. An NDA alone does not cover it.

As people with access. Each developer needs the same controls as an employee:

• Individual accounts on your identity provider, with multi-factor authentication. No shared logins.
• Least-privilege access: repository and staging access by default, production access only by approved exception.
• Access reviews on a schedule, with evidence that someone checked.
• Same-day removal of access when someone leaves the project.
• Security awareness training and acceptance of your policies, recorded.
• Device expectations, such as disk encryption and screen lock, written into the contract.

For a Type 2, expect the auditor to pick samples from the period and ask for evidence such as:

• A list of everyone with production access, and the approval behind each grant.
• Pull requests from the period, showing a review and passing checks before merge.
• Tickets for people who joined and left, with the dates their access was granted and removed.
• Records of each scheduled access review.
• Proof of a restore test and of completed security training.

If a contractor's access was removed a week after they left the project, that can appear as an exception in the report your customers read.

These cost little to set up on day one and a lot to retrofit before an audit:

• Code in your organization. Repositories in your GitHub or GitLab organization, never a vendor's account.
• Branch protection. No direct pushes to the main branch; every change goes through a pull request with at least one reviewer and passing tests.
• Separation of duties. The person who writes a change should not be the only person who approves its release to production.
• Infrastructure as code. Cloud resources defined in Terraform or a similar tool, so changes are reviewed and logged like application code.
• Synthetic data outside production. Developers work with test data on staging. Real customer data stays in production.
• Logging and alerting. Central logs, retained for an agreed period, with alerts on sign-in anomalies and privilege changes.
• Backups and restore tests. A backup proves little until you have restored from it, so schedule restore tests and keep the results.

Our cloud and DevOps work sets up this baseline: pipelines, environments, logging, backups and access policies in your own cloud accounts.

Hosting on AWS, Azure or Google Cloud helps, but it does not make your product SOC 2 compliant. The provider is responsible for its data centers and underlying services; you are responsible for how you configure them, who has access and what your application does with data. Your report will usually point to the provider's own SOC report for the parts it runs. AWS, for instance, makes its SOC 2 report available to customers through AWS Artifact.

Use these questions in vendor selection:

• Will all code live in our repositories and all infrastructure in our cloud accounts from day one?
• Can your developers work entirely without production customer data?
• How do you remove a developer's access when they leave, and how fast?
• Will you follow our security policies and sign our security addendum and NDA?
• Can you provide evidence for our auditor, such as training records and signed policy acknowledgments?
• Do you hold your own SOC 2 report or ISO 27001 certificate, and if not, how will you work inside our controls?

Our model answers the last question with the second option: source code, repositories and cloud accounts are in the client's name, developers work under the client's access rules, and we sign an NDA on request. That keeps the evidence your auditor needs in systems you control. Our SaaS development projects plan for this from the architecture stage.

Do we need SOC 2 before our first enterprise customer?

Not always. Many startups answer early security questionnaires with their policies and a readiness plan, then commit to a Type 1 once a deal depends on it. Building the controls early makes that step faster.

Can offshore developers have production access under SOC 2?

Yes, if access is approved, limited to what the role needs, logged and reviewed. Many companies keep standing production access to a small group and grant temporary access for specific tasks.

How long does SOC 2 take?

Readiness work often takes a few months, and a Type 2 adds its observation period on top. The timeline depends mostly on how many controls already exist when you start.

Do compliance automation tools make us SOC 2 compliant?

They help collect evidence and flag misconfigured settings, but the controls still have to operate and a licensed CPA firm still performs the examination. A Journal of Accountancy piece featured on the AICPA's SOC page warns that promises of "fast and easy" threaten SOC credibility.

Is SOC 2 the same as ISO 27001?

No. ISO/IEC 27001 is an international standard with certification, while SOC 2 is a CPA's attestation report under AICPA standards. Many controls overlap, so work done for one usually helps with the other.

If you are building a SaaS product with an offshore team and expect enterprise security reviews, we can set up the repositories, environments and access model with SOC 2 in mind from the start. After a short discovery call we send a written scope and a fixed quote. Discuss your project.