SOC 2 for a Custom Software Shop: Vanta, Drata or Secureframe

A client hiring a development shop for a project involving their own customer data wants assurance that goes two directions: that your company's internal practices meet SOC 2, and that the specific engagement follows the client's own security requirements, which can be stricter or just different. A platform that only tracks your company-wide controls misses that second layer, and a client's security team will ask about it directly if your SOC 2 report doesn't address multi-tenant or multi-client work at all.

Say your shop runs three active engagements: one with its own AWS account and full infrastructure access, one working inside a client's existing cloud environment with scoped permissions, and one that's mostly frontend work with no production access at all. The controls that matter differ for each. The first needs full evidence collection, same as any SaaS company's infrastructure. The second needs evidence that your team's access into the client's environment is scoped correctly and reviewed on schedule, evidence that often has to come from the client's own systems, not yours. The third barely needs infrastructure evidence at all, but still needs evidence that your laptops, source control, and offboarding process meet the bar.

CISA's binding operational directives set remediation windows of 15 days for critical vulnerabilities and 30 for high severity on internet-facing systems¹, and that standard is a reasonable one to apply to any engagement where your team has production access, regardless of whose cloud account it runs in.

Vanta is often chosen for its integration breadth and speed, which can help if most of your engagements are similar in shape and you want a fast baseline SOC 2 report to show prospective clients during sales. Drata's continuous, infrastructure-level testing fits better when at least some engagements give your team direct production access across multiple cloud accounts, since it catches configuration drift per environment rather than assuming one flat setup. Secureframe's hands-on auditor support helps most when your engagements vary enough in structure that a generic control template doesn't quite fit any of them, and you want someone to help you write policy language that actually describes what you do.

The trickiest evidence gap for a dev shop is access that lives in a client's environment rather than your own. None of the three platforms can pull evidence directly from a client's AWS account without that client granting integration access, which most won't. The practical workaround is documenting your own internal process, how access requests are approved, how offboarding revokes client-side access within a set window, as your control, even when the underlying system is theirs. Auditors accept this as long as the process is consistent and evidenced on your side.

A shop that races to a first SOC 2 report to close one big client deal can let the controls lapse once that deal closes, then scramble again a year later for the Type II renewal. Continuous monitoring tools exist specifically so that doesn't happen, but only if someone owns checking the dashboard, not just the initial setup. Budget an ongoing, even if small, amount of engineering time for this every month rather than treating compliance as a project with an end date.

Habits that keep SOC 2 controls from lapsing after the first report:

• Keep continuous monitoring switched on after the first report, rather than treating it as a project that ends at issuance.
• Assign a named owner to review failing controls on a regular schedule instead of only before renewal.
• Plan for the Type II renewal from the start, so you are not rebuilding evidence a year later.
• Re-check that new client engagements are added to the platform's scope as soon as they begin.

Larger clients sometimes want more than your SOC 2 report, they want their own security team to run a questionnaire or even a short assessment before signing a statement of work. A current SOC 2 Type II report shortens this considerably, since most of the questions a client's security reviewer would ask are already answered in the report itself, but it rarely eliminates the step entirely for a first engagement with a new client. Keep a standard, current response template for common follow-up questions, network diagram, incident response summary, subprocessor list, so this step takes days rather than weeks each time a new client's security team asks.