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 company | In the SOC 2 system? | Reason |
| Accelerator servers in the colocation racks | Yes | Customer jobs and data are processed there |
| Cloud control plane, API, console and billing | Yes | Customers sign in, submit work and get results through it |
| SDK, compiler, drivers and firmware used in production | Yes | Changes to them change what the service does |
| Customer models, inputs and outputs | Yes | Customer data the service stores and processes |
| Identity, HR and endpoint management | Yes | They control who can reach production |
| RTL design, verification and physical design | Usually no | The design flow produces silicon, which reaches the service only as new hardware |
| Lab and bring-up hardware | Usually no | In 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 company | SOC 2 treatment | What goes in the vendor file |
| Colocation facility | Subservice organization, usually carved out | Its SOC 2 report, CUEC mapping, cage access list |
| Cloud provider for the control plane | Subservice organization, usually carved out | Its SOC 2 report, your own account configuration |
| Foundry | Vendor under CC9.2 | NDA, confidentiality terms, secure design transfer, risk tier |
| OSAT | Vendor under CC9.2 | Confidentiality terms, test data handling |
| EDA and cloud EDA vendors | Vendor under CC9.2 | Security 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 category | When a compute provider on custom silicon includes it |
| Security | Always; every SOC 2 report contains the common criteria |
| Availability | Contracts promise uptime or capacity; A1.1 covers capacity monitoring and forecasting |
| Processing Integrity | Customers rely on correct, complete results, such as FHE or accelerator outputs |
| Confidentiality | Customers send proprietary models or data, or the company wants design IP covered |
| Privacy | The 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:
- Name the service the report covers, in the words customers use in contracts.
- Draw the data flow from API to control plane to colo racks and back.
- Separate the design environment from production identity, repositories and networks, and record it.
- Bring compiler, firmware and runtime repositories under CC8.1 controls.
- Sort third parties into subservice organizations and vendors, and update contracts for confidentiality and incident notice.
- 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
- SOC 2 for Hardware Startups: What's in Scope When You Sell Devices, Chips or Appliances
- Contract Manufacturers and SOC 2: Subservice Organization, Vendor, or Out of Scope?
- What Is a Neocloud? Definition, Examples, and What It Means for Compliance
- SOC 2, ISO 27001 and HIPAA for Infrastructure Providers: One Program, Three Outputs
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
- AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
- AICPA, 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022)
- AICPA, Guide: SOC for Supply Chain
- IEC Webstore, ISO/IEC 27001:2022 Information security management systems - Requirements
- Samsung Semiconductor Newsroom, Understanding the semiconductor ecosystem, part 2
- Wikipedia, GDSII
- Synopsys, Licensing QuickStart (Synopsys Common Licensing and FlexNet)
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
Contact Us
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.