SOC 2 for Developer Tools: Scope Code, Tokens, and Hosting

SOC 2 for developer tools starts with the service you provide, not the fact that developers use your product. A hosted API, a repository integration, a customer-run package, and a managed deployment give your company different access and duties. Write down what your company operates, what customer code or credentials it can reach, how it ships changes, and what customers operate themselves. Then ask the report user and a CPA firm which service, report type, and period they need.

Does a developer-tool startup need SOC 2?

No product category creates a universal SOC 2 deadline. A buyer may ask for a report because your service can read source code, run jobs in its pipeline, or hold deployment credentials. Another buyer may accept a security review focused on the integration and your release process. Ask what assurance the buyer requires before promising a report or setting a date. The startup decision guide covers that first conversation.

The AICPA’s SOC 2 Description Criteria address management’s description of a service organization’s system. Its Trust Services Criteria provide the criteria for evaluating controls over the selected categories. The report covers a defined system and specified date or period. A public source repository, package license, or cloud provider’s report does not by itself describe or examine the service your company operates.

Choose the service boundary before the controls

List each way customers use the tool. One company may support several modes, and a report about one mode should not be presented as covering all of them.

Delivery model	What your company may operate	What to verify with the CPA firm
Hosted application or API	Runtime, storage, access, monitoring, support, and release path	Which product, environments, data, providers, and commitments belong in the system
Repository or pipeline integration	App permissions, tokens, webhooks, jobs, logs, and any hosted control plane	Which customer resources the integration can reach and which controls your team operates
Customer-installed package	Builds, releases, update channel, support, and any vendor-managed service	What service the company actually supplies and which installation duties stay with the customer
Managed customer deployment	Deployment, support access, upgrades, monitoring, and agreed operations	Which duties your team performs in the customer’s environment and how both sides divide them

This is a discovery table, not four standard SOC 2 scopes. A purely customer-operated installation may leave your company with a narrower service than a hosted platform, but do not assume the remaining release or support work automatically qualifies for a particular report. Define the offered service, customer commitments, system components, and exclusions with the CPA firm. The general scope guide shows how to test that boundary.

Trace code, credentials, and customer data

For a representative customer, follow the permission path from installation through daily operation and removal. A developer tool may never store a full source repository, yet still receive a short-lived token, a webhook payload, a build log, or a support export that contains sensitive data.

Write a small data and authority map:

1. What does the customer install or authorize, and which repository, organization, environment, or project can it reach?
2. Which permissions are read-only, write, or administrative? Can the tool change code, workflows, secrets, or deployments?
3. Where do tokens, payloads, logs, artifacts, and support copies go, and how long are they kept?
4. Who can change the integration, its permissions, the service code, and the production configuration?
5. What happens when a customer uninstalls the tool, revokes access, or ends the service?

For a GitHub App, GitHub’s permissions documentation shows how repository and organization permissions shape what the app can do. Use the current platform documentation for each integration you actually offer. Do not claim every connection is read-only because the first install flow looked narrow. Check its granted permissions and resulting behavior.

Show how releases reach customers

If your company builds a package, signs a release, runs a hosted service, or updates a customer environment, the change path is part of the proposed boundary. A pull request can show a reviewed source revision, but it does not prove which artifact was built or what the customer received. Connect the source revision to the build, approval, package or image identity, publication, and any later rollback or patch.

NIST’s Secure Software Development Framework recommends protecting software from tampering, producing secure releases, and responding to vulnerabilities. It is useful engineering guidance, not a separate SOC 2 checklist. Design controls for your actual service, risks, and commitments, then use the change management evidence guide to collect complete source records for every in-scope release path.

Public source can help a customer inspect code. It does not establish who had publish access, whether a build matched a reviewed revision, or whether the company followed its own response process after a security report.

Name the customer’s part of the system

Some developer tools require the customer to choose repositories, restrict integration permissions, secure its own runner, rotate a credential, or apply updates. State those duties precisely instead of suggesting your company operates the customer’s entire environment. Also state what your company still owns: its service, release channel, support process, or any privileged access it retains.

The guide to complementary user entity controls explains how management can describe customer actions that its control design depends on. A responsibility statement is not a way to erase a dependency from scope. Review the wording against the real architecture and ask the CPA firm to assess it for the engagement.

Keep the work reviewable without moving secrets into Git

FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. A founder-led team can connect its proposed System, Components, information, vendors, controls, owners, and evidence references to the service boundary. Starter records are proposals, not compliance claims.

Keep operational proof in its authoritative source system. Source control, identity, CI, cloud, support, and customer systems operate the controls and produce their logs and records. FileGRC can organize approved fixed artifacts or safe references, but it does not operate those systems, audit source code, or judge whether evidence is sufficient. Do not put plaintext tokens, keys, secrets, or customer data that may need erasure into Git. The CPA firm performs the independent examination and issues the report.