SOC 2 for Chip Startups: Design IP, EDA Environments, Foundries and Compute Services

Reviewed by Ali Aleali, CISSP, CCSP · Last reviewed October 18, 2026

SOC 2 for a semiconductor company covers the service customers buy, such as hosted compute, an API, SDK delivery and the customer data behind them, and the chip design flow usually stays outside the report. The design or compiler team comes into scope when its code reaches production, and the foundry is a vendor managed under CC9.2, outside the list of subservice organizations.

At a glance

  • What SOC 2 covers: The service customers use: hosted compute, API, console, SDK and driver delivery, customer data
  • Chip design and EDA: Usually out of scope; customers still ask how design IP is protected
  • Compiler, firmware and runtime teams: In scope when their code runs in production or reaches customers
  • Foundry and OSAT: Vendors under CC9.2, with confidentiality commitments in the contract
  • Subservice organizations: The colocation facility and cloud provider, usually carved out
  • Categories to consider: Security, plus Availability and Processing Integrity for compute services
  • ISO 27001: A good pair when partners want the whole company, including design, covered

A typical case is a custom-silicon company offering compute as a service. Its accelerators are in colocation racks, a cloud control plane handles sign-up, scheduling, billing and the API, and customers download an SDK and compiler. A separate team writes RTL in an EDA environment and sends finished designs to a foundry. An enterprise customer's security review then asks for a SOC 2 report and how the company protects its chip designs.

What Does SOC 2 Cover at a Semiconductor Company Selling Compute?

SOC 2 at a semiconductor company covers the system that delivers the service named in the report, and for a compute business that is the hosted service. The AICPA Trust Services Criteria define system boundaries as the specific aspects of an entity's infrastructure, software, people, procedures, and data necessary to perform a function (such as producing, manufacturing, or distributing a product) or provide a service.

Part of a chip companyIn the SOC 2 system?Reason
Accelerator servers in the colocation racksYesCustomer jobs and data are processed there
Cloud control plane, API, console and billingYesCustomers sign in, submit work and get results through it
SDK, compiler, drivers and firmware used in productionYesChanges to them change what the service does
Customer models, inputs and outputsYesCustomer data the service stores and processes
Identity, HR and endpoint managementYesThey control who can reach production
RTL design, verification and physical designUsually noThe design flow produces silicon, which reaches the service only as new hardware
Lab and bring-up hardwareUsually noIn scope if it shares credentials, networks or a deploy path with production

A company that also sells boards or chips as physical goods has a second option for that part of the business. The AICPA's SOC for Supply Chain reports on the description of a system for manufacturing, producing and distributing goods, and SOC 2 stays the report for the hosted service.

Is the Chip Design or Compiler Team in SOC 2 Scope?

A chip design or compiler team is in SOC 2 scope when the code it writes reaches production. SOC 2 CC8.1 covers how the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives, and the auditor traces production software back to the team that wrote it.

Three groups at a custom-silicon compute company usually meet that test:

  • Compiler and SDK engineers. The compiler turns customer models into accelerator instructions, so a compiler change alters what the service computes.
  • Firmware and runtime engineers. Firmware and runtime code loaded onto production cards are software changes under CC8.1, even though the silicon is fixed after tape-out.
  • Platform engineers who build the control plane, scheduler and deployment pipeline.

RTL designers and verification engineers usually fall outside the system, because their output goes to a foundry and returns as new hardware months later. That boundary holds when the design environment has its own identity groups, repositories and networks; a shared admin account or CI runner can pull it into scope. The SOC 2 SDLC guide for self-hosted GitLab covers review and pipeline evidence for the repositories that are in scope.

Key insight

Keep the chip design environment and production apart on purpose.

Separate identity groups, repositories and runners give the auditor a clean boundary, and they also protect the design IP.

How Chip Companies Protect Design IP and EDA Environments for Customer Security Reviews

Design IP and EDA environment security come up in customer security reviews even when both are outside the SOC 2 system. The Trust Services Criteria Confidentiality category covers information such as trade secrets and intellectual property, and the CC2.1 point of focus Classifies Information names intellectual property as a class to identify.

An EDA environment that answers those questions well has controls like these:

  • Classification. RTL, netlists, layout databases and third-party IP blocks are labelled confidential, with licence terms recorded.
  • Segmentation. The design compute farm, storage and license servers (such as Synopsys Common Licensing on FlexNet) are on their own network, reachable through SSO with MFA from managed devices.
  • Access reviews. Quarterly reviews of who can read design repositories and project storage, with removal on offboarding.
  • Tape-out transfer. The final layout file, typically GDSII or OASIS, goes to the foundry through an approved, encrypted channel, with a record of who released it.

Adding the Confidentiality category and the design environment to the SOC 2 system gives customers independent assurance, with more controls to sample. Covering it in an ISO 27001 scope or in questionnaire answers is lighter. The ISO 27001 A.8.4 access to source code guide covers repository access controls that apply equally to RTL.

Is a Foundry or OSAT a SOC 2 Subservice Organization?

A foundry or OSAT is usually a SOC 2 vendor, outside the list of subservice organizations. A subservice organization is a vendor whose controls are needed, together with the company's own, to meet the service commitments in the report, and the system description discloses it under the AICPA description criteria. Foundries manufacture the chips a fabless company designs, and OSATs package and test them; neither operates the hosted service customers use. If a packaging or test partner loads production firmware or injects device keys for you, it performs part of your service and belongs on the subservice organization list.

CC9.2 still applies. It asks for specific requirements for vendor and business partner engagements that include (1) scope of services and product specifications, (2) roles and responsibilities, (3) compliance requirements, and (4) service levels.

Third party at a chip companySOC 2 treatmentWhat goes in the vendor file
Colocation facilitySubservice organization, usually carved outIts SOC 2 report, CUEC mapping, cage access list
Cloud provider for the control planeSubservice organization, usually carved outIts SOC 2 report, your own account configuration
FoundryVendor under CC9.2NDA, confidentiality terms, secure design transfer, risk tier
OSATVendor under CC9.2Confidentiality terms, test data handling
EDA and cloud EDA vendorsVendor under CC9.2Security review, especially if they host design data

The guide to SOC 2 vendor management with a data center as a subservice organization covers the carve-out method, and the guide to complementary user entity controls covers mapping each facility CUEC to a control.

How to Scope a Colo Data Plane and a Cloud Control Plane for SOC 2

A colo data plane with a cloud control plane is one SOC 2 system, because customer jobs and data cross between the two. The system description names both sides, the link between them, and the carved-out facility and cloud provider.

Custom silicon adds work on the data plane. No provider manages the hosts, so host operating systems, card firmware, BMC access and accelerator drivers are company controls under CC6 and CC7, evidenced through scripted exports and dated records. The SOC 2 hybrid and on-prem scoping guide covers the boundary, the guide to SOC 2 evidence collection without APIs covers the evidence, and the SOC 2 neocloud guide covers rented overflow GPU capacity.

Which SOC 2 Trust Services Criteria Fit a Chip Company Selling Compute?

A chip company selling compute usually starts with Security and adds Availability and Processing Integrity, because customers rely on the service being up and on its results being correct. The SOC 2 Trust Services Criteria guide covers all five categories.

SOC 2 categoryWhen a compute provider on custom silicon includes it
SecurityAlways; every SOC 2 report contains the common criteria
AvailabilityContracts promise uptime or capacity; A1.1 covers capacity monitoring and forecasting
Processing IntegrityCustomers rely on correct, complete results, such as FHE or accelerator outputs
ConfidentialityCustomers send proprietary models or data, or the company wants design IP covered
PrivacyThe service processes personal information under its own privacy commitments

The AICPA defines Processing Integrity as System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives. Two of its criteria fit compute services closely:

  • PI1.3: The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
  • PI1.4: The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.

For an accelerator service, the evidence is concrete: published precision and supported operations as the specification, compiler regression and accuracy test suites as processing controls, and job logs that tie each output to its input and to the compiler and firmware versions used. For Availability, capacity forecasts under A1.1 include the next hardware order, since new capacity depends on the company's own silicon.

How SOC 2 and ISO 27001 Work Together at a Semiconductor Company

SOC 2 and ISO 27001 cover different parts of a semiconductor company, so the two pair well. ISO/IEC 27001:2022 specifies requirements for an information security management system whose scope the company sets, so it can include the design environment, tape-out process and foundry relationships. SOC 2 reports on the hosted service that compute customers buy.

One security program supports both, with controls written once and mapped to ISO 27001 Annex A and the SOC 2 criteria. The ISO 27001 to SOC 2 mapping guide shows the overlap, and the SOC 2 vs ISO 27001 comparison covers when each one wins deals.

SOC 2 Readiness Steps for a Custom-Silicon Compute Company

SOC 2 readiness for a custom-silicon compute company starts with the boundary, because every later decision depends on it:

  1. Name the service the report covers, in the words customers use in contracts.
  2. Draw the data flow from API to control plane to colo racks and back.
  3. Separate the design environment from production identity, repositories and networks, and record it.
  4. Bring compiler, firmware and runtime repositories under CC8.1 controls.
  5. Sort third parties into subservice organizations and vendors, and update contracts for confidentiality and incident notice.
  6. Plan evidence for hosts, firmware and BMCs before the observation period starts.

We see boundary work take longer at hardware companies, because design, firmware and platform teams often share tools by habit. The SOC 2 for bare metal and on-prem infrastructure page lists the controls that change when you run your own hardware, and the contact page is where to book a scoping call.

Related Guides

Building silicon and selling compute?

Truvo scopes SOC 2 across your colo data plane, cloud control plane and design teams, then collects the evidence.

Frequently Asked Questions

Does SOC 2 apply to semiconductor companies?

SOC 2 applies to a semiconductor company that provides a service, such as hosted compute, an API or an SDK delivered online. The report covers that service and the customer data behind it. For chips or boards sold as physical goods, the AICPA's SOC for Supply Chain is the matching report.

Is chip design in scope for a SOC 2 audit?

Chip design is usually out of SOC 2 scope, because RTL, verification and layout produce silicon and deliver no part of the hosted service. It comes into scope when the design environment shares identity, repositories or pipelines with production, or when the company adds the Confidentiality category to cover design IP.

Is a foundry a subservice organization under SOC 2?

A foundry is usually a SOC 2 vendor managed through CC9.2. Subservice organizations operate controls the service depends on, such as the colocation facility and the cloud provider. The foundry's vendor file holds the NDA, confidentiality terms, the secure design transfer method and a risk tier. The exception is a partner that performs part of your service, such as loading production firmware or injecting device keys; that partner moves to the subservice organization list.

Which SOC 2 criteria should an accelerator or FHE compute provider choose?

An accelerator or FHE compute provider usually starts with Security, adds Availability when contracts promise uptime, and adds Processing Integrity when customers rely on correct results. Processing Integrity evidence includes published precision specifications, compiler test suites and job logs that tie outputs to inputs.

Should a chip company get ISO 27001 or SOC 2 first?

A chip company selling compute to US enterprise buyers usually starts with SOC 2, because buyers ask for a report on the service. ISO 27001 suits companies whose foundry partners, IP licensors or international customers want the whole organization covered, including design. One control set can support both.

Sources

Ready to Start Your Compliance Journey?

Get a clear, actionable roadmap with our readiness assessment.

Contact Us

Share this article:

Sample SOC 2 Control List

Input your email to download the list.

About the Author

Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.