People, Processes, and Technology Scope Components in SOC 2 System Descriptions

A SOC 2 system description is the document, written by management rather than the auditor, that defines the boundaries of the system under audit. The auditor's job with respect to this section is narrow but consequential: render an opinion on whether the description is accurate, complete, and consistent with the AICPA's defined criteria.

That narrowness affects audit scope directly: whatever the description omits falls outside what the auditor tests. An auditor tests what the description says exists. Leaving a system, a vendor, or a team out of the description causes it to fall outside the audit's scope entirely, whether or not it actually touches customer data. This is the scope mechanic that catches organizations off guard: the description isn't a formality wrapped around the "real" audit work, it defines what the real audit work even covers.

Customers reading the report rely on this section for information they otherwise have no way to get: the vendor's governance structure, who owns what, which third parties touch the data, and what the customer itself is expected to configure or monitor on their own end. Most companies preparing for their first SOC 2 spend the bulk of their energy on implementing controls, firewalls, access reviews, logging, and treat the write-up as a paperwork step at the end. Drata's guidance on this point is blunt: the system description is "frequently overlooked until late in the process," which is exactly backward given how much of the audit's scope depends on it. Typically the longest section of a SOC 2 report, the system description may include graphics, network diagrams, organizational charts, and narrative.

The AICPA DC 200 framework that governs what must appear in the description

The document governing all of this is the AICPA's 2018 SOC 2 Description Criteria, with implementation guidance revised in 2022, published by the Assurance Services Executive Committee.

DC1 covers the types of services provided. DC2 covers the principal service commitments and system requirements a company has made to its customers. DC3, the criterion this piece is built around, requires disclosure of system components: infrastructure, software, people, procedures, and data. DC4 addresses system incidents stemming from control failures. DC5 covers the trust services criteria and controls actually in scope for the engagement. DC6 covers complementary user entity controls, the responsibilities a vendor shifts onto its customers. DC7 covers subservice organizations and how they get disclosed. DC8 explains why any trust services criteria were excluded. DC9, relevant only for Type 2 reports, covers significant changes during the audit period.

Availability, Processing Integrity, Confidentiality, and Privacy are optional based on services provided, and the description must address whichever criteria are in scope.

DC3 maps "people, processes, and technology" onto five concrete components

DC3 uses five components: infrastructure, software, people, procedures, and data.

The mapping is straightforward once you see it laid out. "Technology" in the common shorthand actually splits into two separate DC3 sub-components, infrastructure and software. "Processes" maps to procedures. "People" maps to people. And then there's data, a fifth component that many teams instinctively fold into "technology" because it feels like it belongs there, but DC3 requires it to stand on its own.

This distinction isn't pedantic. Teams drafting against the three-part mental model tend to combine infrastructure and software into a single undifferentiated section, and they tend to skip data as its own disclosure entirely, treating it as an afterthought mentioned in passing wherever it's convenient. Both mistakes leave real gaps. And the five components don't operate in isolation from each other: a control described under procedures has to trace back to a named person who runs it and a piece of infrastructure it runs on, and auditors will follow that thread end to end. A procedure needs a named owner and a system attached to it to count as a procedure from an audit standpoint. It's a claim.

Technology in scope: what infrastructure and software disclosures must cover

Infrastructure, as DC3 defines it, covers hardware, servers, workstations, networks, facilities, and data storage devices, physical and virtual alike. The description needs to lay out system boundaries clearly and address any third-party access into the system. In practice, this section usually combines narrative text with structured component lists and, frequently, network or architecture diagrams, since a diagram often communicates a boundary faster than a paragraph can.

The decision about how to handle cloud infrastructure providers sits inside this component. A company running on AWS, GCP, or Azure must be disclosed as either in-scope via the inclusive method or excluded via the carve-out method. A carve-out disclosure reads something like this: the organization relies on AWS, but the report does not cover AWS's own controls, so the user entity is responsible for reviewing AWS's SOC 2 report on its own, which tells the customer exactly where their own due diligence has to pick up. That's not a technicality buried in fine print. It tells the customer exactly where their own due diligence has to pick up.

Changing cloud providers during an audit period isn't a quiet infrastructure update, either. Linford & Co. states that a hosting provider swap during the audit window triggers a disclosure obligation under DC9, because it's the kind of change that could affect how a reader interprets the rest of the description.

Software, the second sub-component, covers the application programs, operating systems, mobile apps, and utilities that support the service in scope. A table listing each vendor software product alongside its function tends to work better here than a narrative block. Not everything belongs in this table, though. Internal tools like payroll systems or chat platforms generally sit outside the boundary, since the test is whether the software directly supports the product or service under audit, not whether the company happens to use it. Auditors check this section for completeness above all: if a system supporting a described control is missing from the technology disclosure, that control effectively has no home.

People in scope: roles, departments, and governance structures the description must name

The people component asks for more than a list of job titles. DC3 requires disclosure of the departments, teams, and functions actually involved in security, governance, development, and the day-to-day operation of controls. Descriptions usually open this section with narrative on the governance structure, then back it with an organizational chart, though the chart alone doesn't satisfy the requirement.

Third parties belong here too. A vendor or subcontractor that supports the offering isn't outside the people component just because it isn't on the internal payroll; if it plays a role in delivering the service, it needs a place in the description.

The underlying reason auditors care so much about this section comes down to traceability. A control has to connect to a named individual or team, because auditors gather evidence by following the control back to whoever actually owns it. A control with no named owner is, functionally, untestable. Segregation of duties lives here as well: the description needs to make clear which teams hold which responsibilities and where the separation between them actually sits.

Descriptions frequently fall short in exactly this section. Many treat the people component as a box-checking exercise, a department list with no real explanation of how those teams interact with the controls they supposedly own, and auditors have gotten sharper about noticing when a people section is substantive versus when it is merely ornamental. Part of the fix is organizational rather than editorial: a description drafted entirely by the compliance team, without input from engineering, security, and operations, tends to miss the operational roles that actually run day-to-day controls.

Processes in scope: the operational procedures that make controls real and testable

DC3's procedures component isn't asking for a list of policies. It's asking how those policies actually get executed, step by step, day to day. A policy that says access gets reviewed quarterly is not a procedure. The procedure is who initiates that review, what system generates the list of accounts, and what happens when the review turns up an exception.

Four areas tend to draw the closest auditor attention. Change management sits at the top: formal request and approval steps for any system change, along with documentation, and testing in a separate environment before anything reaches production. Incident response follows close behind, covering continuous monitoring, a defined response plan, log collection, alerting, and, ideally, some evidence that the process has actually handled a real incident at some point. Access provisioning and de-provisioning covers the full lifecycle: onboarding workflows, role-based access assignments, multi-factor authentication enforcement, and periodic reviews of who still needs what.

Auditors use this section to figure out what evidence they should expect to find. A vague procedures section doesn't protect an organization from scrutiny, it does the opposite: it gives the auditor room to expand requests or start questioning whether the description is complete. Describing a control's existence without describing its mechanics, who triggers it, what approval gates it, what artifact it leaves behind, leaves the whole section effectively unverifiable. Vendor risk within processes in scope covers how external services are assessed and monitored, including review of vendor SOC 2 or ISO 27001 reports, data-sharing agreements, and the supplier risk register.

Data as the fifth DC3 component, treated alongside the other four

Data stands apart from infrastructure and software under DC3, even though it's tempting to treat it as something that just rides along with whatever system stores it. The description needs to spell out the types of data entering and leaving the system, how that data gets classified, and where it actually resides, whether that's flat files, internal databases, or external storage.

A data-type table paired with a flow diagram tends to communicate this more clearly than narrative alone, since data movement is inherently a "who talks to whom" question that a diagram answers faster than a paragraph. Beyond just describing where data lives, the description also has to address the controls protecting it: what stops unauthorized access, and what risk management processes are in place around each data type.

DC3 is the criterion most directly at stake here, the one that requires disclosure of the five system components. Getting it right requires engineering to map the actual data flows, legal to confirm what classifications apply, and security to explain what controls govern each classification, and those three functions rarely report into the same person, let alone collaborate on a single document by default. If Confidentiality or Privacy sits among the Trust Services Criteria in scope, the data component has to carry enough detail to actually support testing against those criteria.

Interlock of the Components with the Other DC Criteria Beyond DC3

DC3 doesn't operate in isolation from the rest of the framework. DC2 requires that the commitments a company makes in customer contracts and SLAs show up consistently in the description, and those commitments need to connect back to whichever Trust Services Criteria are in scope. If Availability is one of them, availability metrics need to actually appear under DC2, not just be implied.

DC6 covers complementary user entity controls, the responsibilities a vendor is explicitly shifting onto the customer. If a description states that the user entity is responsible for configuring IP allowlists, that sentence is doing real work: it tells the customer the vendor isn't testing or guaranteeing that particular protection, full stop.

DC7 has to line up with whatever infrastructure decisions were made earlier in the document. The inclusive-versus-carve-out choice for a cloud provider can't just live in the infrastructure section; it has to appear consistently everywhere that provider is mentioned. A vendor named under infrastructure but never disclosed under DC7 is exactly the kind of inconsistency an auditor is trained to flag.

DC9, which only applies to Type 2 reports, requires disclosure of any material change to people, processes, or technology during the audit window, a personnel change in a control-owning role, a new cloud provider, a revised incident response plan. All of this adds up to a coherence test that a well-drafted description has to pass: the controls listed under DC5 need to be executable by the people named under DC3, through the procedures described under DC3, running on the infrastructure and software also disclosed under DC3. When that chain holds together end to end, the description reads as one coherent account of a real system. When it doesn't, the gaps are exactly where an auditor's questions start.

Type 1 vs. Type 2 timing and the description's differing role between them

Type 1 and Type 2 reports ask different questions, and the system description's role shifts accordingly. A Type 1 evaluates whether controls are suitably designed at a single point in time, so the description tends to get written before or alongside the audit fieldwork itself. A Type 2 evaluates whether those controls actually operated effectively over a stretch of time, often somewhere between three and twelve months, so the description gets finalized close to the end of that observation window, and DC9's disclosure requirements for significant changes come into play.

Enterprise buyers almost always demand Type 2 because design alone does not demonstrate that controls operated day-to-day. Design without evidence of consistent operation isn't much of an assurance.

There's a real cost to getting the description wrong at either stage. It goes through the same quality control review as the rest of the audit, so a late or sloppy description holds up the entire final report. Worse, a misstated or incomplete description can produce a qualified opinion. Drata's guidance states that omitting a subservice organization that an auditor later determines would have made the description misleading without it is grounds for exactly that kind of qualification.

Common failure modes that produce an incomplete or qualified description

A handful of mistakes appear repeatedly in weak descriptions, visible when auditors compare sections against what the underlying teams actually do. Thin people sections top the list: department names with no explanation of how those teams actually touch the controls attributed to them. Thin procedures sections follow close behind, policies asserted to exist with no named owner, no approval step, and no evidence artifact described anywhere.

Missing system components create a harder problem, because whatever infrastructure or software gets left out of the description is, by definition, outside the audit's scope, whether or not it touches customer data in practice. Folding data into the infrastructure section instead of giving it standalone treatment produces a related gap: classification and data flow never get independently addressed the way DC3 actually requires.

Subservice organization inconsistency is its own recurring failure mode: a cloud provider named under infrastructure but never disclosed under DC7, or a carve-out claimed without telling the reader what they now need to do on their own end to compensate. And then there's language itself. The AICPA specifically singles out what it calls "advertising puffery", subjective or marketing-style language, as inappropriate in a system description, because the document is supposed to be an objective account of how the system actually operates, not a sales pitch dressed up as an audit artifact. Every one of these failure modes traces back to the same root cause, treating the description as paperwork instead of as the document that actually defines what got audited. DC9 omissions involve significant changes to people, processes, or technology during a Type 2 period that are not disclosed, such as a personnel change in a control-owning role, a new cloud provider, or a revised incident response process.

Drafting a system description that holds up to scrutiny: process and ownership

Management owns this document. Auditors may hand over a template or a structured questionnaire, and some will even draft initial language from management's answers for review, but the accuracy and completeness of the final text is management's responsibility.

Engineering, security, operations, and compliance all need a seat at the table, because no single team has visibility across all five DC3 components at once. Compliance alone can produce a document that reads well because compliance drafted it without input from engineering, security, and operations, and such a document can still miss half the operational reality those teams would have surfaced.

Two drafting approaches occur in practice. One is template-based, where the auditor supplies a structured outline and management fills in each section directly. The other is questionnaire-based, where management answers a set of questions and the auditor drafts language from those answers, with management reviewing the result for accuracy before anything gets finalized. Either way, starting early gives gathering accurate input from multiple stakeholders, locking down subservice organization scope decisions, and producing clean diagrams the time they take, since none of it compresses well under deadline pressure.

Before submission, a coherence review pays for itself. Walk through every control listed under DC5 and confirm it has a named owner in the people section, a documented procedure in the procedures section, and a system in the infrastructure or software section. Any gap found at that stage is cheap to fix. The same gap found by an auditor becomes a finding, and a finding found by a customer reading the final report becomes a much harder conversation.