Does a SOC 2 cover software a customer runs on its own servers?
A SOC 2 examines the controls of the services you operate and the system behind them, not the environment your customer runs your software in. An independent CPA firm issues the report, but your organization owns the controls, the system description and the evidence. When a bank or enterprise buyer asks for SOC 2 while your product ships to its own data center or cloud account, the first question is where your operations end and the customer's begin, because that boundary decides scope, cost and effort. Components you host, such as a license server, a update endpoint, a telemetry service or a support portal, usually fall inside the examination. Binaries the customer installs and runs on hardware you never touch generally sit on the customer's side of the line.
Write that boundary down before anyone talks to an auditor. List every component, mark who operates it, who holds the credentials and who can change it, then decide which items the system description must cover. The AICPA's description criteria expect management to explain the services provided, the system components and any subservice organizations, so a vague boundary produces either an over-broad report or a finding later. Confirm with your CPA firm how it treats components that run only in customer environments, and whether customer-side responsibilities belong in complementary user entity controls.
The report type also shapes effort. A Type 1 report describes the system and tests whether controls are suitably designed as of a single date, which can be a faster first step for a narrow scope. A Type 2 report adds an opinion on whether controls operated effectively over an observation period, and buyers in regulated sectors usually ask for it. Ask your auditor which report type fits your boundary and how long the observation period needs to run before a Type 2 can be issued.
Which components a vendor usually puts in scope
Some self-hosted vendors still operate components their customers depend on, such as license validation, update and download endpoints, telemetry collection and a customer portal. These run in the vendor's own cloud accounts, so they are the components most clearly inside a SOC 2 system description. The controls here are the usual service controls: access to production hosts, change management under CC8.1 for every release of the service, and vulnerability handling under CC7 for the internet-facing endpoints.
- Access to production: Named roles, MFA, and access reviews for everyone who can reach license servers, download buckets or portal databases.
- Change management: Authorization, testing and approval for infrastructure and configuration changes to hosted components.
- Vulnerability handling: Scanning and patch timelines for the hosts and images behind each endpoint.
- Logging and monitoring: Retained logs for authentication, administrative actions and endpoint availability.
- Outside the report: Software that customers install and run on their own servers is generally not part of the vendor's system, though the vendor's hosted endpoints it talks to usually are.
Confirm with your CPA firm which hosted endpoints it treats as part of the system, and document any that customers can run on their own infrastructure.
Support is where vendors most often touch customer environments directly. Ticketing systems hold customer data, remote access tools open sessions into systems the vendor does not own, and engineers may be granted temporary access to diagnose a fault. Auditors usually expect these to be in scope because the vendor controls who can enter a customer environment and under what authority, which is a logical access question under CC6.
- Ticketing and attachments: Who can view customer tickets, how attachments are stored and how long they are retained.
- Remote access tools: Approved tools, session recording where available, and removal of unused accounts.
- Customer-environment access: Written customer approval, time-limited credentials and a record of what was accessed during each session.
- Escalation and incident handling: Criteria for when a support case becomes a security incident under CC7.
- Outside the report: The customer's own environment and the customer's decisions about granting access, unless the contract makes the vendor responsible for them.
Ask whether the support model involves standing access or per-session approval, because the answer changes which controls the auditor will test.
For self-hosted software, the release pipeline is part of the product's security. A compromised build or stolen signing key can put malicious code into every customer installation, so auditors look closely at how code moves from source control to a signed artifact. The change management controls in CC8.1 cover authorization, development, testing, approval and implementation, and the secure development practices in NIST SP 800-218 give a common vocabulary for describing them.
- Source control: Branch protection, mandatory review and restricted rights to merge to release branches.
- CI runners: Ephemeral or hardened runners, controlled secrets and a record of each build's inputs.
- Signing keys: Storage in a key management service or hardware module, restricted signing rights and logged use.
- Artifact repositories: Access controls, immutability of published versions and checksums that customers can verify.
- Outside the report: Open-source dependencies the vendor consumes are only partly in scope, so document how they are reviewed and updated.
Confirm with the CPA firm how the signing process and artifact publication are described, since customers often rely on them for their own supply chain reviews.
Corporate systems include email, identity provider, HR platforms, finance tools, laptops and office networks. They are often in scope for SOC 2 because they hold access to production and to the people who make changes. Vendors frequently include them under the entity-wide criteria, including CC1 to CC3, and the access controls that govern who can reach the production systems above.
- Identity and single sign-on: Central authentication, MFA and the link between joiner and leaver records and production access.
- Endpoints: Device management, disk encryption, malware protection and an inventory of company laptops.
- Joiner, mover and leaver process: Timely removal of access when staff leave or change roles.
- Policies and training: Security policies, acknowledgments and awareness training for staff with privileged access.
- Outside the report: Personal devices and accounts used outside company control, and office facilities if the vendor is fully remote.
When a vendor is small, corporate systems are often the first place auditors find gaps, so confirm that the identity provider and device inventory cover everyone with production rights.
What secure development evidence auditors expect from a software vendor
When customers run your software in their own infrastructure, the auditor looks at how you build, review, and release that software, not at their environment. The cards below cover the development evidence that connects the change criteria in CC8.1 to the artifacts your customers actually install, and they use NIST SP 800-218 as a shared vocabulary for the practices involved.
Change authorization and testing
CC8.1 covers every stage of a change, from authorization and design through development, configuration, documentation, testing, approval and implementation. For a vendor, the auditor will want a ticket or pull request tied to each release that shows who authorized the change, what tests ran, and who approved the deployment. Confirm whether your issue tracker and CI system already link these records. Gaps usually appear in hotfixes and emergency releases.
Code review and branch protection
Auditors test whether changes to production code get independent review before merge. Branch protection rules that require an approving reviewer who is not the author, and that block direct pushes to release branches, turn that expectation into an enforced control rather than a habit. Ask your engineering lead to export the current branch protection settings and the review history for a sample of recent releases, since those exports are the evidence an auditor will sample.
Dependency and third-party component management
Self-hosted products are assembled from open-source libraries, base images and build tools, and customers inherit the risk of each one. Keep a software bill of materials for every release, record which components are reviewed and approved, and show how you flag new vulnerabilities in those components. Confirm that your scanners cover container images and transitive dependencies, not only the direct packages your team chose.
Vulnerability intake and patch release
Vendors need a documented path for reports that arrive from customers, researchers and scanners, with severity assessment, owners, target dates and a record of when each fix shipped. Auditors compare the intake log against release records to test whether issues were fixed on your stated timeline. Confirm who triages reports, how security advisories reach customers who run the software themselves, and whether you keep records of patches delivered to customers' environments.
Signing and integrity of released artifacts
Customers who self-host need assurance that the package they install is the one you built. Signed release artifacts, published checksums and a documented build provenance record let a customer verify integrity before deployment. Confirm which signing keys exist, who can use them, where they are stored, and how key rotation and revocation are recorded. The keys themselves are a high-value asset and fall within the access and secrets evidence an auditor will request.
Secure development practices and training
NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1 published in February 2022, gives vendors a common vocabulary for secure development practices that can be built into any software development lifecycle. Use its practice groups as a checklist of what your team already does, then document the gaps. Confirm which practices leave records you can show an auditor, such as threat models, secure coding training completions and security reviews of design changes.
Where a SOC 2 fits next to other AICPA and assurance reports
A SOC 2 covers your controls over security, availability, processing integrity, confidentiality or privacy, while a SOC 1 covers controls relevant to a customer's internal control over financial reporting. For a vendor that installs software in the customer's own environment, the SOC 1 is rarely the right question, because the customer's financial reporting controls do not depend on your build pipeline or your support desk. Before anyone commits to a report, ask the customer which of the five trust services categories they actually care about, and whether they need a report they can share widely or one restricted to their own review. A SOC 3 is a general use report that covers the same categories in less detail and can be freely distributed, which makes it useful for a public trust page, but it does not replace the detail a security reviewer wants from a SOC 2.
The AICPA also publishes a supply chain guide and a cybersecurity guide, and vendors sometimes confuse them with SOC 2. The supply chain guide is aimed at examinations of controls in production, manufacturing or distribution systems, and the cybersecurity guide covers an entity's cybersecurity risk management program. Neither is a default substitute for a SOC 2. If a customer asks for assurance that the software they install is the software you built, unchanged and free of tampering, that is a question about software integrity, and it may need a different scope, a different assessment or evidence drawn from your build and release process. Confirm with a CPA firm which report matches that request before you accept a scope the customer has described in a questionnaire.
Treat the report choice as a decision to record, not a formality. Write down the request in the customer's words, the systems and services it touches (for example, the support portal, the release signing process or any hosted license service), and the report the CPA firm recommends. Ask the firm to explain why the chosen report answers the request and where it does not. An implementation partner can prepare the system description and evidence for whichever examination is chosen, but only the independent CPA firm decides the report type and issues the opinion.
How the scoping and audit process runs for a self-hosted vendor
The sequence below takes a self-hosted software vendor from an agreed system boundary to an issued SOC 2 report, with a named output at each stage. Ask your CPA firm for its own timeline before you commit to any date with a customer.
Agree the system boundary and services with management
Management, usually the CEO or CTO with the head of support and the release engineering lead, decides which services the SOC 2 covers. For a self-hosted vendor this often means the support portal and ticketing, the update and license delivery channel, the build and signing pipeline, any hosted licensing or telemetry components, and the corporate systems that touch them. Customer-run installations in their own infrastructure are usually outside the boundary, and the customer's controls there are normally described as complementary user entity controls. The output is a short scope statement that names each in-scope service, its owners, and the excluded components, which the CPA firm reviews before fieldwork planning begins.
Write the system description against DC 200
Management writes the description of the system using the AICPA 2018 description criteria, DC1 to DC9, which cover services, commitments, system components, incidents, applicable criteria, complementary user entity controls, subservice organizations, and significant changes. For a self-hosted product, the description should state clearly which customer-hosted deliverables the vendor does not operate, how releases reach customers, and which cloud or hosting providers support the vendor's own services. The output is a draft description that the CPA firm evaluates for completeness and accuracy, with open questions resolved in writing.
Map chosen criteria to controls and owners
The team selects the trust services categories in scope, with security covering the common criteria CC1 to CC9 in every case, and maps each applicable criterion to a documented control, an owner, a frequency, and the evidence that will show the control ran. For a self-hosted vendor, change management under CC8 and vulnerability handling under CC7 usually carry the most weight because they govern what reaches customer environments. The output is a control matrix that the CPA firm reviews, with any criteria excluded as not relevant recorded and justified in the description.
Prepare evidence for the examination period
For a Type 1 report, the team prepares evidence that controls were designed and in place on one specified date. For a Type 2 report, it collects evidence that controls operated consistently across the observation period, such as signed release approvals, access review records, ticket samples, and build logs. Evidence should come from the systems themselves wherever possible, and each item should be traceable to a control in the matrix. The output is an evidence index, organized by control, that lets the auditor select samples without asking for material that was never kept.
Complete CPA fieldwork and sampling
The CPA firm plans its procedures, requests evidence, selects samples, and tests whether controls were designed effectively and, for a Type 2, operated effectively over the period. For a self-hosted vendor, the auditor may also ask how a customer-facing release was built, signed, tested, and approved, and whether any hosted component changed during the period. Exceptions are discussed with management before the report is drafted. The output is a list of findings or exceptions with management responses, which the team resolves or records in the report.
Sign the management representation letter
Management signs a written representation letter confirming the accuracy of the system description, the completeness of the information provided to the auditor, and the disclosure of known exceptions, incidents, and subsequent events. This follows the assertion-based approach of the attestation standards, under which the service auditor obtains written representations from management. Signing this letter is a management responsibility, and the output is a signed letter dated to the report, held in the audit file and reflected in the final report.
Receive and distribute the issued report
The CPA firm issues the SOC 2 report, which includes the auditor's opinion, management's assertion, the system description, the criteria and controls, and test results. The report is an independent document that the vendor cannot write or alter, and it is generally restricted in use to customers and prospects under NDA. Ask the CPA firm for its own schedule for each stage before you commit to any customer date, since timing depends on scope, evidence readiness, and firm capacity. The output is the signed report, which the team reviews for scope accuracy before sharing it.
What a SOC 2 for a self-hosted vendor costs and who gets paid
This table lists each cost component of a SOC 2 for a self-hosted software vendor, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, and check the SOC 2 cost guide for published ranges before comparing offers. The main takeaway is that the CPA firm fee is only one line, and the scope you choose for the services you operate drives most of the rest.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| CPA firm examination fee | Independent CPA firm (the only party that issues the report) | Type 1 is one-time; Type 2 repeats each review period | Number of criteria in scope, the observation period, and how many hosted components the auditor must test |
| Implementation partner scoping and evidence preparation | Implementation partner, under a written fixed scope | One-time for setup, with possible recurring evidence support | How many self-hosted deployments you support, whether controls cover your hosted components only, and how much evidence is already collected |
| Tooling and monitoring | Software vendors and cloud providers | Recurring subscriptions or hosting costs | Whether you use open-source tools you run yourselves or paid GRC platforms, and the size of your build and support infrastructure |
| Internal engineering and security time | Your own staff (payroll cost, no external invoice) | Recurring, with a heavier first year | Number of people with change, access and release responsibilities, and how well policies and tickets already match the work |
| Penetration test used as supporting evidence | Independent penetration testing firm | Usually recurring per test cycle | Scope of the hosted services and update channels tested, and whether you test customer-deployed builds in a lab |
| Customer-side and auditor follow-up | Your own staff and, where contracted, the implementation partner | Recurring around each customer review and audit cycle | Volume of customer questions about where the report stops, and whether the system description clearly separates your scope from the customer's environment |
What makes a self-hosted SOC 2 larger or smaller
A SOC 2 for a self-hosted vendor covers only what the vendor operates, not the software as customers run it. The six factors below decide how much of the vendor's own environment and people an examiner tests, so each one is a scope decision the vendor can shape before the examination starts.
Vendor-operated services in scope
Every service you run for customers, such as a hosted license server, update distribution, a support portal or telemetry collection, adds system description content and controls to test. Inventory each one and decide whether it is in the system boundary. A service you never touch after delivery, like a customer-installed binary, is usually outside it. Confirm the boundary with your CPA firm in writing before you commit to a Type 1 date.
Support access to customer environments
If support engineers can log into customer clusters, VMs or air-gapped networks, those access paths fall inside your logical access and change controls, and the examiner will ask how each session is approved, recorded and revoked. Narrowing access to customer-initiated, time-boxed sessions with logged commands usually reduces the testing burden. Ask whether any support path bypasses the customer's own controls, since the examiner will want that described.
Build and release record maturity
Change management under CC8.1 expects each change to be authorized, tested, approved and deployed with a record. Vendors whose releases come from tagged, peer-reviewed commits with automated test results have ready evidence. Vendors who ship from ad hoc builds on a laptop face a larger sample of changes to reconstruct. Review your pipeline logs, signing practices and release notes against NIST SP 800-218 before the examination window opens.
Subservice organizations such as cloud hosts
Each third party that runs part of your service, such as a cloud provider, a CDN, an artifact registry or a managed database, is a subservice organization. You can carve out its controls and rely on its own SOC report, or include it in scope and test it directly. Carve-out keeps the examination smaller but requires you to collect those reports, map complementary subservice controls and review exceptions each year.
Categories beyond security
Security is the required category, and each addition brings its own criteria: availability adds capacity, backup and recovery testing, confidentiality adds classification and disposal, and privacy adds a long list of notice and retention requirements. A self-hosted vendor rarely needs privacy unless it collects personal data from its own operations. Start with security and add a category only when a named customer or contract asks for it.
Hosted components beside self-hosted software
If you also run a hosted version, a managed instance or a SaaS control plane next to the self-hosted product, that hosted part is the most likely to need full SOC 2 controls. Decide whether the report covers only the hosted services, the operations behind both models, or both, and write that boundary into the system description. Buyers of the self-hosted product may ask whether the report applies to them at all, so state it plainly.
Who does what: vendor, implementation partner and CPA firm
The software vendor is the service organization. It decides which services are in scope, owns every control described in the report, and signs the management assertion and representation letter that the examination depends on. Management also writes the system description, so the vendor must be able to explain what it operates, what customers run themselves, and where responsibility passes to the customer.
- Scope decisions: Choose which services, such as support, updates, build pipeline and any hosted components, fall inside the system boundary.
- Policies and control ownership: Write, approve and run the policies, and name an owner for each control in the control matrix.
- System description: Prepare the description against the 2018 description criteria, including complementary user entity controls for what customers must do in their own environments.
- Management assertion: Sign the written assertion and the representation letter that the auditor relies on.
- Ongoing operation: Perform the controls day to day, because operating effectiveness is tested over the observation period.
Before engaging anyone, confirm that a named executive can sign these statements and that the team can run the controls without outside help.
An implementation partner such as DeployOpen helps the vendor prepare the systems and evidence the controls depend on. The partner works inside the boundary the vendor sets, and the vendor remains accountable for the outcome. A partner does not issue a SOC 2 report, opinion or attestation, and does not decide whether a control is effective.
- Boundary planning: Map which hosted components, build systems and support tooling are inside the system, and which sit with the customer.
- Configuration and documentation: Configure access control, logging, change workflows and backup tooling, and document how each runs.
- Evidence collection: Set up the systems that produce records, such as access reviews, change tickets and vulnerability scan output, so the vendor can hand them to the auditor.
- Readiness support: Help the vendor test its own controls before fieldwork, and report gaps to management for decision.
- Scope limits: Work is fixed in writing, and the partner does not sign management statements or talk to the auditor on the vendor's behalf unless the vendor authorizes it in writing.
Ask any partner to put in writing which deliverables it produces and which decisions stay with the vendor's management.
A licensed CPA firm performs the SOC 2 examination as the service auditor. It tests the design and, for a Type 2, the operating effectiveness of controls over a period, obtains written representations from management, and issues the report with its opinion. Its independence is the reason the report has value to customers, so the firm cannot design the controls it later tests.
- Independent testing: Select samples, inspect evidence and interview staff without any role in building the controls.
- Opinion and exceptions: Issue the report, including any exceptions or modified opinions.
- Engagement letter: Agree scope, timing, fees and responsibilities in writing before fieldwork begins.
- Report types: Decide with management which report fits the need, such as SOC 2 Type 1 or Type 2, and whether a SOC 3 general use report is also issued.
- Independence rules: Consulting help with the same controls can affect independence, so ask the firm how it separates readiness work from attestation.
Confirm the firm's licensing and its independence policy before signing, and check whether it can also prepare you, since that often limits its ability to audit you.
Common questions about SOC 2 for self-hosted software vendors
Can a SOC 2 cover code our customers run themselves?
Usually not the customer-run software itself. A SOC 2 examines the services and system that the vendor operates, such as support access, software updates, the build and release pipeline, and any hosted components like licensing servers or update endpoints. The customer's copy of the software runs in infrastructure the vendor does not control, so the customer's own controls over that environment fall outside the vendor's report. The practical question is where the vendor's responsibility starts and stops, and that boundary should be written into the system description. Confirm with your auditor how the boundary will be drawn before you commit to a report date.
Do we need a SOC 2 if we never host customer data?
It depends on what your customers ask for and what your company operates. A SOC 2 reports on controls relevant to security, availability, processing integrity, confidentiality or privacy at a service organization, so it is not limited to vendors that store data. Even when customers host everything, a vendor may still operate a support portal, a license server, a telemetry service or a build pipeline that customers rely on. Those services can be in scope. If your product has no operated component and no customer-facing service, a SOC 2 may add little, and a customer may accept a different answer. Ask the customer which controls they need to evaluate before you assume either way.
What does a customer's bank expect when the product runs in its own data center?
Banks generally want to know how the vendor controls its own operations and how it manages risk from the relationship, even when the bank keeps the data in its own facilities. Their third-party risk programs apply to the vendor regardless of where the software runs, so they will ask for independent assurance about the services the vendor provides, such as remote support, patch delivery and access to the bank's environment. The US interagency guidance on third-party relationships, published in the Federal Register in June 2023, frames these expectations. Expect questions about who can access the bank's systems, how that access is logged and how changes reach the bank. A SOC 2 can answer some of these, but banks often add contract terms and their own assessments on top.
Can we do this ourselves?
Often yes, if someone on the team owns the program and has time for it. The work includes defining the system boundary, writing the description, documenting the controls, collecting evidence on a schedule, and working with an independent CPA firm through fieldwork. None of that is done by a consultant on the vendor's behalf in a way the auditor relies on, because the auditor tests the vendor's own controls. Outside help is commonly used for gap assessment, control design, evidence tooling and readiness reviews, while the vendor keeps ownership of its controls and the report is issued only by the independent auditor. Ask any partner to state which parts they prepare and which parts remain with your team.
How long does it take, and what does the work need from our engineers?
The duration depends on how much of the control set already exists and how many people must change how they work. A Type 1 report covers control design as of one date, while a Type 2 report covers operating effectiveness over a period, so the observation window is the main driver of a Type 2 timeline. Engineers mainly need to document the build and release process, maintain change records, define how support accesses customer environments, keep dependency and vulnerability tracking current, and produce logs or tickets that show the controls ran. Get a written schedule and an estimate of engineering hours from any firm you hire, tied to the agreed scope. No fixed duration applies to every vendor.
What if support engineers access customer systems?
That access is usually the highest-risk part of the scope and the first thing an auditor and a bank will examine. Controls typically cover who may request access, how approval is recorded, how access is time-limited and scoped, whether sessions are logged, how credentials are protected, and how access is reviewed and removed. Support access to a customer environment should be traceable to a ticket or a documented customer request. Confirm with your auditor whether these activities sit inside your SOC 2 boundary or are governed by the customer's own controls, and document the answer in the system description so reviewers see the same picture you do.
How DeployOpen prepares a self-hosted vendor for its SOC 2
DeployOpen works on the systems a self-hosted vendor operates, such as support tooling, update delivery, the build pipeline and any hosted components, and prepares the controls and evidence an independent CPA firm will test. The vendor owns its controls and its report, and DeployOpen does not issue audit reports or attestations.
How we scope
- We agree a written scope that lists the services and system components the vendor actually operates for customers.
- We separate what the vendor runs from what customers run in their own infrastructure, so the description matches reality.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We prepare access controls, change management and build pipeline evidence for the hosted and operated components in scope.
- We review secure development practices against the vendor's release process, mapping them to the criteria the CPA firm will test.
- We set up logging, monitoring and vulnerability handling so that the records an auditor samples already exist.
How we hand over
- We document the system description, control matrix and evidence index so the vendor and its CPA firm can follow them.
- We agree which customer-side responsibilities belong in complementary user entity controls, and document them clearly.
- We test controls before the examination and report gaps to the vendor, who decides how to remediate them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- A retainer can keep evidence current between audit periods, which matters for a Type 2 observation window.
- Questions about the auditor's requests can be routed to our team, while the CPA firm decides what it accepts.
