SOC 2 for API companies and developer tools

Everything else is the same examination every software company sits for. The criteria do not change for developer tools. What changes is which ones your facts make loud, and which artifacts already exist in the tools your engineers use every day.

What sits inside the boundary

The system description has to say what is in scope and what is not.¹ For an API business, draw it around four things.

• Production. The infrastructure that answers requests, its databases, and the cloud accounts they live in.
• The continuous integration and delivery (CI/CD) pipeline. Whatever can build and deploy is a path into production, so its permissions and its runners are in scope.
• Secrets. Database credentials, signing keys and the provider tokens your pipeline uses. A leaked deploy token is a production access problem.
• The repository that ships. Public or private.

Open source does not change that. Public read access says nothing about write access, and write access to the branch that deploys is a logical access control like any other. Branch protection can require approving reviews and passing status checks before a merge.² That configuration, and who can change it, is what gets tested.

A public repository brings one free control with it. GitHub runs secret scanning on public repositories automatically.³ It does not replace a secrets manager. It does give you an alert log to point at.

Uptime promises and the Availability category

Security is the one category every SOC 2 includes. Availability is optional, and it tests capacity planning, backup and recovery infrastructure, and recovery testing.⁴ The question for an API company is whether you have promised availability in writing.

Read your contracts, not your marketing. A service level agreement (SLA) with an uptime figure and service credits is a commitment. A status page is a disclosure of how you are doing; on its own it promises nothing. If customer agreements carry an uptime commitment, the scoping tool will tell you Availability may belong, and how many criteria a SOC 2 covers shows what adding it costs in controls.

Be clear about our limit here. Polara G.R.C. scopes Security only, fixed rather than a setting. A Security only report does not test your uptime commitments. If a contract needs Availability tested, a firm that runs that scope directly is the right route.

Change evidence from pull requests

Change management asks that changes are authorized, designed, tested and approved before they reach production.⁴ If you ship through pull requests, that record already exists. It lives in the pull request.

A merged pull request with a required approving review, passing checks, and a linked ticket is one change, fully evidenced. The auditor asks for the population of merges to the production branch in the period, picks a sample, and opens each one. Merges that bypassed protection are the exceptions, so admin overrides need their own record.

Two edge cases deserve a written answer before fieldwork. Emergency fixes need a path that is fast and still reviewed afterwards. Dependency bumps from a bot are changes too. The GitHub integration collects the branch protection settings, meaning required reviews and status checks. The list of merges for the period is an export you take from GitHub yourself. A change management policy should name both edge cases.

Customer payloads in your logs

An API that logs requests and responses is storing customer data in a second place. Often a third and a fourth: the log pipeline, the observability vendor, the error tracker. Each copy has its own retention and its own access list.

Decide three things and write them down. Which fields are logged at all. How long logs are kept, with a setting you can show. Who can read them, which should be a shorter list than who can deploy. SOC 2 log retention covers the defaults in the usual cloud services, and a logging and monitoring policy is where the answers belong.

Cloud, observability and model providers

Your cloud host is a subservice organization. So is any vendor your service commitments depend on: the observability platform holding your logs, the queue, the email provider for account notices, and any model provider your API calls.⁵ A small company carves them out, names them, and states the controls it relies on each one to run.

Those statements are complementary subservice organization controls, and how to word CUECs and CSOCs shows the difference between a useful one and a decorative one. If your API wraps a model, the guide for AI companies covers prompts as customer data and what each provider publishes about its own report. If your API moves money, the guide for fintech covers what a bank partner reviews.

API keys and customer access

API keys are two controls in one object. Your half is the lifecycle: keys issued with a scope, stored hashed or in a secrets manager, rotatable by the customer, revocable at once, and logged when used. Admin access to the system that issues keys is production access, and gets reviewed like it. An access control policy sets those rules.

Your customer’s half is keeping the keys secret. That belongs in your description as a complementary user entity control. Without it, your report reads as if you guarantee something only the customer can do.

What a customer’s review is checking

A customer evaluating an API vendor may send its own questionnaire or a standard one. The Cloud Security Alliance publishes the Consensus Assessments Initiative Questionnaire (CAIQ) v4, a set of yes or no questions a cloud customer may ask a cloud provider.⁶ For an API vendor, its access, change management, logging and supply chain questions land on the sections above.

A SOC 2 report answers many of those with one document. The rest, such as data residency, are answered by your own written statements.