When to Make SOC 2 a Hiring Requirement for a Software Studio

The decision rule: follow control, access, and consequence

A sensible requirement starts with the operating arrangement, not the studio’s sales material.

Make SOC 2 a **strong contract gate** when both of these conditions are present:

1. The studio will host or operate the finished system, retain standing privileged production access, or process sensitive data in its own systems. 2. The project involves confidential, regulated, financial, or operationally critical information or functions.

Treat SOC 2 as **optional supporting evidence** when the studio only writes code in buyer-owned accounts, has narrowly limited access, and will leave no continuing operational dependency after handoff. You should still request secure-development, access, testing, dependency, vulnerability, and offboarding evidence.

Escalate rather than guessing when the work involves regulated or financial data, major operational consequences, unresolved report exceptions, or contractual security obligations. In those cases, the acceptable gate may be a relevant SOC 2 report, another independent control assessment, a product-security assessment, or a combination selected by a qualified reviewer.

This risk-based approach aligns with NIST’s software supply-chain guidance, which recommends matching validation rigor to the criticality and assurance requirements of the product or service. NIST notes that first-party attestations may be acceptable unless the risk justifies independent assessment or more detailed evidence.

What a SOC 2 report can—and cannot—establish

A SOC 2 report examines controls within a service organization’s **defined system**. According to the AICPA’s SOC 2 reporting guidance, those controls may be relevant to security, availability, processing integrity, confidentiality, or privacy.

That definition contains the reason a badge is insufficient: the report is bounded. Its value depends on what system was examined, which criteria were included, what period was covered, what exceptions were found, and how subservice organizations were handled.

Before treating a report as evidence, inspect:

- **The legal entity:** Is the contracting studio the organization named in the report? - **The defined system:** Does it include the development, hosting, support, or production-access service you are buying? - **The criteria covered:** Does the examination address the concerns that matter for this project? Security may matter in every case; availability, processing integrity, confidentiality, or privacy may also matter depending on the system. - **The examination period:** Does it provide useful evidence about the studio’s present operating practices? If the period ended earlier, ask what materially changed afterward. - **The controls and tests:** Which controls were examined, and what did the examination actually test? - **Exceptions:** Were control failures or deviations reported? What caused them, what was affected, and what corrective evidence exists? - **Subservice organizations:** Which cloud, support, monitoring, or other providers are involved, and which of their controls fall outside the report? - **The project mapping:** Can the studio show how the examined controls apply to your repository, environments, data, deployment process, and support arrangement?

A relevant report can establish that specified controls in the defined system were independently examined for the stated period. It does **not**, by itself, prove that your application has no vulnerabilities, that its business logic is correct, that every dependency is safe, that backups can restore your particular system, or that the studio satisfies every law and contract applicable to you.

That product-level gap matters. CISA’s Secure by Demand guidance warns that conventional compliance reviews can emphasize enterprise security while revealing less about product security. A studio can have well-governed internal systems and still deliver a poorly designed or insufficiently tested application. The reverse can also occur: a small studio may have strong project controls but no organization-wide SOC 2 examination.

The buyer-side decision tree

Use this sequence before asking for documents:

```text Will the studio host and operate the finished system? ├─ Yes → Arrangement 3: hosted and operated by the studio └─ No └─ Will it retain standing privileged production access? ├─ Yes → Arrangement 2: studio retains production privileges └─ No → Arrangement 1: development in buyer-owned accounts

Then assign the highest applicable project-risk tier: 1. Public information 2. Confidential internal data 3. Regulated or financial data 4. Operationally critical system ```

“Privileged production access” means the ability to change deployments, configurations, secrets, accounts, production data, or other controls that could materially affect the live system. Temporary, buyer-approved access is not the same as unrestricted standing access, but it still needs authorization and records.

The risk categories can overlap. A system processing public information may also be operationally critical. A confidential internal tool may later become a system of record. Use the highest applicable consequence rather than the most convenient label.

| Studio arrangement | Public information | Confidential internal data | Regulated or financial data | Operationally critical system | |---|---|---|---|---| | **1. Develops only in buyer-owned accounts** | No blanket SOC 2 gate. Request direct development, testing, dependency, access, and handoff evidence. | Usually no blanket SOC 2 gate if data stays in buyer systems. Add access, offboarding, incident, and subprocessor evidence. | Require security or legal review. Ask whether any studio-controlled tool receives the data; request independent assurance for that system when warranted. | Require specialist review, product testing, dependency evidence, rollback and recovery responsibilities. A studio-level SOC 2 helps only if its scope matches the actual risk. | | **2. Retains privileged production access** | SOC 2 may remain optional for a low-consequence system, but access approval, authentication, logging, emergency access, and offboarding evidence are not optional. | Normally request a relevant SOC 2 report or accepted independent alternative, plus project-specific access and incident evidence. | Make relevant independent assurance a pre-contract gate, subject to security and legal review. Do not accept an out-of-scope report. | Require scoped independent assurance plus access records, product testing, incident exercises, vulnerability handling, and tested recovery arrangements. | | **3. Hosts and operates the system** | A low-consequence public site may justify direct evidence rather than a SOC 2 requirement. Reclassify it if availability or integrity has serious consequences. | Normally require a relevant SOC 2 report or accepted independent assessment covering the hosted service. | Require specialist review and independent assurance covering the system and data handling. Add product-level and contractual evidence. | Make scoped independent assurance a contract gate. Confirm that the relevant security, availability, processing, incident, and recovery controls are actually included and tested. |

If a higher-risk studio cannot provide relevant independent assurance, you have three defensible options: reduce its access or hosting responsibility, commission an appropriate independent assessment before signing, or choose another provider. Accepting an irrelevant SOC 2 report is not a fourth option.

Evidence ladders for the three operating arrangements

The evidence request should become more demanding as supplier control and project consequences increase. NIST SP 1326 frames ICT supplier due diligence around ownership and influence, provenance, resilience, foundational cyber practices, and supply-chain tiers. Those categories are broader than a single audit report and are useful for examining how a studio, its software, and its providers fit together.

### Arrangement 1: The studio writes code in buyer-owned accounts

For **public-information work**, request a concise secure-development process map, repository access list, code-review rules, testing approach, dependency inventory, vulnerability contact, and handoff plan. First-party artifacts can be proportionate when consequences are low and you can inspect the work directly.

For **confidential internal data**, add a data-flow description, access approvals, a sanitized offboarding record, the list of subprocessors or development tools that could receive project data, incident contacts, and written confirmation of what access ends at handoff. Confirm that production data will not be copied into unmanaged development tools or environments.

For **regulated or financial data**, do not assume that a SOC 2 report automatically answers the regulatory question. Have a security or legal reviewer map the project requirements to the studio’s controls. If the studio’s own systems will receive the data, request relevant independent assurance for those systems. If the data remains entirely in buyer-controlled systems, a product-security assessment and direct control evidence may be more pertinent than an unrelated organization-level report.

For an **operationally critical system**, add evidence about deployment approvals, rollback, dependency provenance, software-component inventory or SBOM where warranted, vulnerability remediation, production support, recovery responsibility, and the buyer’s ability to operate the system without the studio. Test the handoff rather than treating source-code delivery as proof of operational independence.

### Arrangement 2: The studio retains privileged production access

For a **public, low-consequence system**, request named privileged roles, the approval mechanism, authentication controls, access logs, emergency-access rules, and a revocation process. A SOC 2 report may be optional, but unmanaged standing privilege should not be.

For **confidential internal data**, normally ask for the latest relevant SOC 2 report or another independent assessment. Verify that the examined system includes the remote administration, support, deployment, credential-management, or monitoring functions the studio will use. Add project-specific logs and offboarding records because an organization-level report does not show who can access your environment today.

For **regulated or financial data**, make independent assurance a gate subject to specialist approval. Request a control-to-requirement map, report exceptions and remediation evidence, subprocessor information, vulnerability and incident procedures, and evidence of cyber-insurance coverage relevant to the engagement. Insurance is financial risk transfer, not proof of secure operations.

For an **operationally critical system**, also inspect availability and recovery evidence, emergency-change records, incident exercises, restoration tests, support dependencies, and procedures for continuing operations if the studio becomes unavailable. The report must cover the service that creates the operational dependency.

### Arrangement 3: The studio hosts and operates the system

For **public-information work**, start with the consequences of compromise, defacement, data corruption, or outage. Direct evidence may be proportionate for a low-consequence public system, but a public interface does not make an operationally important service low-risk.

For **confidential internal data**, a relevant SOC 2 report or accepted independent alternative should normally be part of the pre-contract package. Its defined system should include the hosting platform, deployment path, monitoring, administrative access, incident response, backup or recovery functions, and applicable subprocessors.

For **regulated or financial data**, require security and legal review. Ask how data enters, moves through, and leaves the hosted service; where supplier tiers appear; what incident-notification support the studio provides; and which controls are independently examined. Product testing and dependency evidence remain necessary even when the hosting controls have been examined.

For an **operationally critical system**, require independently examined controls relevant to the system’s actual security, availability, processing, confidentiality, or privacy needs. Add current recovery-test results, incident-exercise evidence, product-security testing, an SBOM or equivalent dependency inventory when warranted, patching records, subprocessor dependencies, and an exit plan that can be exercised.

The four-column evidence test

Vendor claims are useful starting points, not conclusions. Use this table to convert each claim into an inspectable request.

| Vendor claim | Evidence to request | What the evidence establishes | What remains unproven | |---|---|---|---| | “We have SOC 2.” | The report or a controlled review of it; named entity; defined system; criteria; period; controls; tests; exceptions; subservice organizations; written mapping to your engagement. | Which defined controls were independently examined, over what period, and with what reported results. | That your application is secure; that your service is in scope; that conditions remain unchanged after the period; or that every applicable obligation is satisfied. | | “We follow secure development practices.” | A process map from requirements through design, coding, review, testing, deployment, vulnerability handling, and maintenance; sample records from comparable workflows with sensitive details removed. | That the studio has a defined way to incorporate security into development. Samples may show that the process is used. | That every project follows it, that the design is sound, or that no exploitable defects remain. | | “Only approved people can access your systems.” | Named role matrix, approval records, authentication requirements, privileged-access records, and a sanitized recent access review. | Who should have access, how it is granted, and whether access is periodically reviewed. | That no undocumented access path exists or that an authorized person cannot misuse access. | | “We remove access when people leave.” | Offboarding procedure and a sanitized completed offboarding record showing account, credential, token, device, and repository actions where applicable. | That revocation responsibilities and evidence exist. | That every account and copied secret was identified or that the process always runs on time. | | “Every change is reviewed and tested.” | Repository rules, sample change records, reviewer evidence, automated test results, release approvals, and the process for emergency changes. | That review and testing controls are configured and used for the sampled changes. | That tests cover the correct risks, business logic is correct, or production configuration matches the reviewed code. | | “We manage software dependencies.” | Dependency inventory or SBOM when warranted, update process, provenance information, exception records, and evidence of dependency scanning or review. | Which components are known and how the studio monitors or updates them. | That the inventory is exhaustive, that every flagged issue is exploitable, or that every component is currently safe. | | “We patch vulnerabilities quickly.” | Vulnerability intake channel, severity and ownership rules, remediation records, disclosure process, and contractual response expectations. | That reports can be received, assigned, tracked, and closed under a defined process. | That every vulnerability will be found or fixed before exploitation, or that the proposed timing meets your obligations. | | “We are prepared for incidents.” | Incident-response plan, contact and escalation list, customer-notification procedure, exercise record, and corrective actions from the exercise. | That roles, communications, and response steps have been planned and exercised. | How the studio will perform in a real event or whether its notification timing satisfies your specific duties. | | “Your system is backed up and recoverable.” | Backup scope, retention and protection description, recovery responsibilities, latest relevant restoration-test record, observed result, and unresolved findings. | That a defined recovery procedure has been tested under the recorded conditions. | Recovery from every failure mode, restoration of every dependency, or performance after the system changes. | | “We carefully manage subprocessors.” | Current subprocessor list, function and data handled by each, location where relevant to your requirements, due-diligence process, contract controls, and change-notification process. | Which supplier tiers are known and how the studio evaluates and governs them. | The full effectiveness of each subprocessor’s controls or the absence of undisclosed dependencies. | | “We carry cyber insurance.” | Certificate of insurance and confirmation that the coverage, limits, material exclusions, and contracting entity are relevant to the engagement. | That a specified policy was represented as active for the named entity at the time of review. | That the claim will be covered, losses will fit within limits, or the studio operates securely. | | “You own the application and can take it over.” | Account ownership, repository and infrastructure access, build and deployment instructions, secret-transfer plan, data-export format, dependency rights, documentation, and a handoff or recovery exercise. | That the buyer has identified assets and a documented path to inspect, build, deploy, and operate the system. | That the team can actually run it without the studio until the handoff has been exercised. |

A polished policy document is weaker than a record showing the policy in use. A screenshot is weaker than a controlled system record. A report whose scope does not map to the engagement may be weaker than direct project evidence. Evaluate each artifact according to the claim it can actually support.

Put assurance requirements in the contract, not only the questionnaire

Security diligence should continue after vendor selection. CISA’s buyer guidance places product-security diligence before procurement, during procurement through requirements and contract language, and after procurement through continuing assessment.

Translate the selected evidence level into terms covering:

- Which party owns and administers each repository, cloud account, domain, data store, monitoring system, and credential. - Whether the studio receives production access, which roles it may use, how access is approved, and when access ends. - Which security requirements are acceptance criteria for the delivered software. - How code review, testing, dependency management, vulnerability intake, and remediation will work during the engagement. - How quickly the studio must notify you of a suspected incident so that you can meet your own obligations. - Which subprocessors are approved and how changes will be communicated. - Who performs backups, restoration testing, incident exercises, and operational recovery. - What report, assessment, or updated evidence must be supplied after a material change or during a longer operating relationship. - How data, credentials, code, documentation, and access are returned, transferred, or deleted at the end.

Do not copy a statutory reporting deadline into every contract without analysis. For products covered by the EU Cyber Resilience Act, however, the European Commission describes an early warning within 24 hours and a fuller notification within 72 hours for actively exploited vulnerabilities or severe incidents. An affected buyer needs a development or operating partner’s escalation process to provide enough information soon enough for the buyer to evaluate and meet its own duties.

Red flags that should pause the purchase

Pause for clarification, narrower access, specialist review, or a different vendor when you encounter any of these conditions:

- The studio displays a SOC 2 badge but will not identify the examined entity, defined system, criteria, period, or exceptions. - The report covers corporate administration while the service you are buying—development, hosted operations, or privileged support—is outside its defined system. - The studio says the report proves that its code is secure. - Report exceptions are dismissed as irrelevant without a project-specific explanation and corrective evidence. - The studio cannot say who will have production access or how that access will be revoked. - Access depends on shared credentials or undocumented accounts. - Security policies exist, but the studio cannot provide sanitized records showing code review, testing, access review, offboarding, vulnerability handling, or recovery in use. - The studio has no clear channel for receiving vulnerability reports or no owner for evaluating and patching them. - Backups are described, but restoration has not been tested for the system or a sufficiently comparable environment. - Subprocessors, development tools, or hosting dependencies are undisclosed. - Cyber insurance is presented as a substitute for operational controls. - The studio’s proposed access or hosting responsibility is broader than the evidence it can support. - The studio will deliver source code but cannot demonstrate how the buyer can build, deploy, recover, and operate it.

A studio does not need to expose sensitive security details without safeguards. Redaction, controlled review, and an appropriate confidentiality agreement can be reasonable. Refusing any meaningful way to validate a consequential claim is different from protecting sensitive details.

An email-ready evidence request

Delete the lines that do not match your project. A low-risk engagement should not receive the same document demand as a regulated or operationally critical hosted system.

> **Subject: Security and operating evidence for [project name]** > > Before we finalize vendor selection, please confirm which operating arrangement applies: > > - Development occurs in our accounts, with no retained production access after handoff; > - Your team retains privileged access to our production environment; or > - Your organization hosts and operates the finished system. > > Please also identify the people or roles that will access our repositories, environments, production systems, or data, and describe how access is approved, reviewed, logged, and removed. > > If your organization has a SOC 2 report, please provide a controlled way to review the latest report and identify the contracting entity, defined system, criteria covered, examination period, reported exceptions, and treatment of subservice organizations. Please explain how the report’s scope maps to this engagement and disclose material control changes after the examined period. > > If no relevant SOC 2 report is available, please identify any independent assessment you propose as alternative assurance and provide the following applicable evidence: > > 1. A map of your secure-development process from requirements through deployment and maintenance; > 2. Sample evidence of code review, testing, release approval, and emergency changes; > 3. Your dependency inventory or SBOM approach where applicable; > 4. Your vulnerability intake, prioritization, remediation, and disclosure process; > 5. Your incident-response and customer-notification process, including the latest relevant exercise; > 6. Your latest relevant restoration or recovery-test record; > 7. Your current subprocessor list and change-notification process; > 8. A certificate of cyber insurance and confirmation of coverage relevant to the contracting entity and work; > 9. Your project offboarding and handoff plan, including access revocation, credentials, code, documentation, data, and account ownership. > > Sensitive information may be redacted or reviewed under appropriate confidentiality controls. Please identify anything that is not applicable and explain why.

The request asks the studio to define its role before producing documents. That prevents a low-value exchange in which the buyer receives a large report without knowing whether it covers the work being purchased.

When security or legal review is warranted

A founder, owner, operations leader, or department manager does not need to interpret every audit exception alone. Obtain qualified security or legal review before signing when:

- The system processes regulated or financial data. - A customer, insurer, lender, regulator, or existing contract imposes security or supplier-assurance duties. - The studio will host the system or retain privileged access to a consequential production environment. - Failure, corruption, or prolonged outage could materially interrupt operations. - The SOC 2 entity, defined system, criteria, period, exceptions, or subservice organizations do not clearly map to the engagement. - The studio offers an alternative assessment, but you cannot determine whether it provides equivalent evidence for the identified risk. - The software may fall under product-security or vulnerability-reporting obligations, including applicable Cyber Resilience Act requirements. - Important supplier ownership, provenance, resilience, or downstream-provider questions remain unresolved.

CISA publishes vendor-assessment guidance specifically for small and midsize business acquirers, including owners, operators, and executives purchasing technology. The goal is not to imitate a large-enterprise questionnaire. It is to identify the few supplier conditions that could create unacceptable exposure and validate them at a proportionate level.