For a startup, SOC 2 usually arrives as a sales requirement: an enterprise buyer or a hospital network sends a security questionnaire, and the deal waits for the report. The work then lands on engineering: who can access production, how code reaches it, what gets logged and how fast leavers lose access. With an outsourced team, each question needs an owner on both sides.
A startup with an external development team can pass a SOC 2 audit when those developers work inside the startup's own identity, code review and logging systems, follow the employee onboarding and offboarding process and are covered by a contract that sets security obligations.
This article explains the engineering controls auditors test, how to split responsibilities with an outsourced team, a month-by-month path to a first Type 2 report and what it costs. It does not cover ISO 27001 or HIPAA in depth, and it is not audit advice.
Key takeaways
- SOC 2 is an attestation report, not a certification. A Type 1 report checks control design at one point in time. A Type 2 report checks that controls worked over an observation period, usually three to twelve months.
- Security, known as the Common Criteria, is mandatory. Availability, processing integrity, confidentiality and privacy are added when customers need them.
- Most engineering evidence comes from four systems: the identity provider, the code repository, the cloud account and the logging and alerting stack.
- External developers with access to production or customer data are in scope as personnel. Their onboarding, training, access and offboarding need the same evidence as employees.
- A realistic path to a first Type 2 report takes nine to twelve months, including a three-month observation period.
- Budget for the auditor, a penetration test, a compliance platform and engineering time. Engineering time is usually the largest cost.
SOC 2 in one table
| Type 1 | Type 2 | |
|---|---|---|
| What the auditor checks | Whether controls are designed properly | Whether controls are designed properly and worked over time |
| Period covered | One date | An observation period, commonly 3, 6 or 12 months |
| Typical first-report timeline | 2–4 months of preparation | 6–12 months, including the observation period |
| What buyers think of it | A useful first step for early deals | The report most enterprise buyers expect |
| Evidence | Policies, configurations, screenshots | Samples of tickets, reviews, logs and approvals across the period |
The AICPA describes SOC 2 as a report on controls at a service organization relevant to the five trust services categories. A startup chooses which categories to include. Most first reports cover security alone, and add availability and confidentiality when customers ask about uptime and data handling.
The engineering controls auditors test
The Common Criteria are numbered CC1 through CC9. Four of them carry most of the engineering work.
CC6: logical access
- Single sign-on for everything. Every person, employee or contractor, signs in to code hosting, cloud consoles, databases, monitoring and ticketing through the company identity provider, with multi-factor authentication enforced.
- Least privilege. Production access is limited to the people who need it, preferably through roles that are granted for a limited time and logged.
- Quarterly access reviews. A named owner reviews who has access to each critical system and records the decision.
- Same-day offboarding. When someone leaves, accounts are disabled within an agreed window, usually 24 hours, with a ticket that proves it.
- Encryption. Data is encrypted in transit and at rest, and keys are managed in a cloud key service rather than in code.
CC7: system operations
- Logging. Authentication events, administrative actions and production changes are logged centrally and kept for an agreed period, often one year.
- Alerting. Alerts on suspicious activity reach a person, and someone acknowledges them.
- Vulnerability management. Dependency scanning runs on every build, container images are scanned, and critical findings have a fix deadline.
- Incident response. A written plan exists, it names roles, and the team runs at least one tabletop exercise a year.
- Backups. Backups run automatically and a restore is tested at least once a year.
CC8: change management
- Protected branches. Nobody pushes directly to the main branch, and every change needs an approved pull request from someone other than the author.
- Automated checks. Tests and security scans run before merge.
- Traceability. Each production change links to a ticket, a pull request and a deployment record.
- Separate environments. Development, staging and production are separated, and production data is not copied to development without masking.
CC9: vendor and risk management
- Vendor inventory. Every vendor that touches customer data is listed, including the outsourcing partner, the cloud provider and AI model providers.
- Vendor reviews. Each critical vendor is assessed once a year, usually by reviewing its own SOC 2 or ISO 27001 report and its contract terms.
When some of your developers work for another company
The auditor examines the startup's system, and anyone who can change that system or see its data is part of it. External developers therefore fall into one of two treatments.
Developers working inside your systems. When outsourced engineers use your identity provider, your repositories and your cloud accounts, the auditor treats them like employees for access and change management. Their accounts are sampled in access reviews, their pull requests appear in change samples and their offboarding is tested. This is the setup that keeps an audit simple.
A partner running part of the system on its own infrastructure. When the partner hosts a component, runs its own CI pipeline or keeps data on its own systems, it becomes a subservice organization. The report then either describes the partner's controls (the inclusive method) or excludes them and relies on the partner's own assurance (the carve-out method). The carve-out method is more common, and it requires the startup to obtain and review the partner's SOC 2 or ISO 27001 report each year.
For most startups, the first option is the better one. It keeps the evidence in one place, and it means the startup can remove access to its own systems at any moment.
Who owns which control
| Control | Startup | Outsourcing partner |
|---|---|---|
| Identity provider, SSO and MFA | Owns and administers | Uses company accounts only |
| Repository rules and branch protection | Sets and enforces | Follows, and reviews peers' code |
| Production access | Grants, time-limits and logs | Requests through the agreed process |
| Background checks | Defines the requirement in the contract | Performs the checks and confirms them in writing |
| Security awareness training | Provides the program or accepts the partner's | Completes training and shares records |
| Device security | Sets the minimum standard | Enforces disk encryption, screen lock and endpoint protection on its laptops |
| Onboarding and offboarding | Creates and disables accounts | Notifies the startup the same day a person joins or leaves the project |
| Incident response | Leads | Reports suspected incidents within an agreed time, such as 24 hours |
| Confidentiality | Includes clauses in the contract | Signs and keeps individual confidentiality agreements |
Every line in this table belongs in the contract. Our guide to software development outsourcing agreements covers the security and data protection clauses in detail.
Evidence auditors ask about external developers
- A current list of external personnel with access, matched to accounts in the identity provider.
- Signed confidentiality agreements and confirmation of background checks for a sample of those people.
- Security training completion records.
- Tickets showing access granted on joining and removed on leaving, with dates.
- Access review records that include the external accounts.
- The contract with the partner, and the annual vendor review.
Building a product that has to pass SOC 2 or HIPAA review? Our teams work inside your accounts and controls, with security processes that hold up in an audit.
Explore healthcare softwareA path to a first Type 2 report
| Month | Work | Output |
|---|---|---|
| 1 | Choose the trust services categories and the scope: which product, which environments, which teams | Scope statement and system description draft |
| 1–2 | Gap assessment against the criteria, often with a compliance platform connected to the cloud, code host and identity provider | Ranked list of missing controls |
| 2–4 | Engineering remediation: SSO everywhere, branch protection, logging, alerting, backups, vulnerability scanning, offboarding automation | Controls in place and producing evidence |
| 3–4 | Policies: access control, change management, incident response, vendor management, data retention | Approved policy set |
| 4 | Penetration test and fixes | Test report and remediation evidence |
| 4–5 | Optional Type 1 audit for early sales conversations | Type 1 report |
| 5–8 | Observation period of three months, with controls running and evidence collected | Evidence for the auditor's samples |
| 9–10 | Type 2 fieldwork and report | Type 2 report |
After the first report, the observation period usually becomes twelve months, and each annual report covers the previous year. A bridge letter covers the gap between the end of one period and the next report.
What SOC 2 costs a startup
These ranges are typical for a startup with 10 to 50 people, one product and a cloud-only setup.
| Item | Typical cost |
|---|---|
| Auditor, Type 1 | $10,000–$25,000 |
| Auditor, Type 2 | $15,000–$50,000 a year |
| Compliance automation platform | $8,000–$30,000 a year |
| Penetration test | $5,000–$25,000 |
| Engineering remediation | 300–900 hours in the first year |
| Ongoing upkeep | 5–10% of one engineer's time, plus a few days a quarter for reviews |
Audit fees vary widely. Linford & Co, an audit firm, puts typical SOC audits at $20,000 to $150,000, with a median of about $30,000, and notes that internal costs often exceed audit fees. Engineering time usually decides the real total, and it is lower when the product was built with access control, logging and code review from the start.
A real program: SOC 2 Type 2 for a healthcare platform
A Canadian healthcare startup, working under NDA, lets patients track chronic pain and share data with clinicians and insurers. Its insurance partners required SOC 2 Type 2 and strict data governance before they would scale contracts. The platform ran on legacy Drupal 6, which could not meet the security requirements.
A .wrk team of a project manager, two backend engineers, a React Native engineer, a frontend engineer, a QA engineer and a DevOps engineer has worked with the company for over five years. For SOC 2, the work covered the system itself and the way it changes.
- Isolating the legacy system. Core services were rebuilt as Symfony microservices, and the legacy Drupal was restricted to admin-only functions that auditors could isolate.
- Remediation sprints. The team ran dedicated SOC 2 remediation sprints alongside product work, so feature delivery did not stop.
- Review and approval gates. Code review gates and role-based approvals were introduced for changes, aligned with HIPAA and PIPEDA requirements.
- Independent testing. Third-party penetration testing was added to the release cycle.
- Faster, smaller releases. The release cycle moved to two- or three-week cycles, which produces cleaner change evidence than large, infrequent releases.
The platform reached SOC 2 Type 2, unplanned downtime stopped after the infrastructure upgrade, where monthly outages had been common, and API calls became about five times faster. The company could sign insurer contracts knowing the platform would pass scrutiny. Read the healthcare platform case study.
Mistakes that slow down a first SOC 2 report
- Contractors on personal accounts. Shared or personal accounts on code hosting or cloud consoles make access reviews and offboarding impossible to prove.
- Policies nobody follows. Auditors test practice, not documents. A policy that requires quarterly access reviews fails if the reviews did not happen.
- Scope that is too wide. Including every internal tool and environment multiplies the evidence. Start with the production system customers use.
- Fixing controls during the observation period. Changes made mid-period create exceptions. Finish remediation before the period starts.
- Forgetting AI and data vendors. Model providers and data tools that process customer data belong in the vendor inventory.
If you build AI features, our guide to an AI governance framework covers the controls that sit alongside SOC 2 for models and prompts.
Frequently asked questions
Do startups need SOC 2?
There is no legal requirement, but many enterprise, healthcare and financial buyers require a SOC 2 report before they sign. Startups selling to these buyers usually start the process when the first large deal depends on it.
How long does SOC 2 take for a startup?
A Type 1 report usually takes two to four months of preparation. A first Type 2 report usually takes nine to twelve months, including remediation and an observation period of at least three months.
Can an outsourced development team be part of a SOC 2 audit?
Yes. External developers who work inside the startup's identity provider, repositories and cloud accounts are treated like employees for access and change controls. The startup needs contract terms, onboarding and offboarding records, training records and access reviews that include them.
What is the difference between SOC 2 Type 1 and Type 2?
A Type 1 report assesses whether controls are designed properly at a single point in time. A Type 2 report assesses whether those controls operated effectively over an observation period, usually three to twelve months.
How much does SOC 2 cost for a startup?
Auditor fees typically run $10,000–$25,000 for Type 1 and $15,000–$50,000 a year for Type 2. A compliance platform, a penetration test and engineering time add to that, and engineering time is often the largest part.
To sum up
SOC 2 for a startup is mostly an engineering exercise: single sign-on everywhere, protected branches, central logging, tested backups and a clean offboarding process. External developers fit into an audit without trouble when they work inside the startup's own systems and the contract spells out who owns each control.
.wrk builds and maintains software for healthcare, fintech and other regulated companies in the US, Canada and Europe, with teams that work inside the client's security controls and support SOC 2, HIPAA and PIPEDA requirements.
Preparing for SOC 2 with an external team? Tell us about your product and audit timeline, and we will propose a team that works inside your controls from day one.
Explore healthcare software