9.5 System Description Criteria, Boundaries, Service Commitments & Complaint Channels

System Description Criteria, System Boundaries, Service Commitments & Complaint Channels

Quick Answer: Five Area III tasks close here, and they all orbit the system description in Section III of a SOC report. Define service commitments and system requirements and how they correspond to the entity's objectives referred to in the Trust Services Criteria. Explain the purpose and common sections of a system description. Obtain an understanding of the system, including clear identification of the boundaries of the system as defined by the service organization. Perform procedures to understand how the organization tells personnel and external users how to report failures, incidents, concerns and complaints. And prepare a comparison of management's description to the suitable criteria in a SOC 1 engagement or to the description criteria in a SOC 2 engagement.

---

1. Service Commitments and System Requirements

The Trust Services Criteria are written in terms of achieving "the entity's objectives." Two defined concepts supply the content of those objectives in a SOC 2.

• Service commitments are the declarations the service organization makes to its user entities about the system: in master services agreements and service level agreements, in the published privacy notice, on the public website, and in standardized terms of service. Examples: "customer data is encrypted at rest and in transit," "99.9% monthly availability," "terminated user access is removed within 24 hours," "data is stored only in the European Union."

• System requirements are what the system must do in order to meet those commitments and to comply with law, regulation, contracts and the entity's own policies. They are internal and often more granular than the commitment. A commitment to encrypt data at rest becomes system requirements such as "AES-256 encryption on all production storage volumes," "customer-managed keys rotated annually," and "no unencrypted volume may be provisioned."

How They Connect to the Criteria

      Service commitments                 System requirements
   (what we promised customers)      (what the system must do to keep
                |                     the promise and comply with law)
                +-----------------+---------------------+
                                  |
                       The entity's objectives
                    referred to in the Trust Services Criteria
                                  |
                          Controls designed and
                       operated to achieve the criteria
                                  |
                    Service auditor's opinion: were the
                  applicable criteria achieved, in all
                       material respects?

Three consequences follow, and each is examinable:

1. The criteria are constant; the yardstick is not. Two organizations are evaluated against identical availability criteria, but one committed to four-hour recovery and the other to seventy-two hours. The same failover test result produces opposite conclusions.
2. Over-committing manufactures findings. A marketing page promising "military-grade encryption and 24/7 monitoring" becomes a service commitment the auditor will test. Management should reconcile public statements to what the system actually does before the examination, not during it.
3. The description must disclose them. The 2018 description criteria require management to describe its principal service commitments and system requirements — one of the two significant additions those criteria introduced. A description that omits them is not fairly presented.

---

2. Purpose and Common Sections of a System Description

Purpose. The description is management's own account of the system, written so that a report user with a reasonable understanding of business and IT can determine whether the system is relevant to that user's needs, understand which controls the service organization operates and which it expects the user entity to operate, and evaluate the auditor's opinion in context. It is prepared by management, not by the service auditor — the auditor opines on whether it is fairly presented.

Governing criteria. In a SOC 2 the benchmark is the description criteria in DC section 200. In a SOC 1 the description is evaluated against the suitable criteria set out in AT-C 320 and the AICPA SOC 1 guide.

The Nine Description Criteria for a SOC 2 (DC Section 200)

Management's description must address:

System incident disclosure deserves separate emphasis: the 2018 criteria require management to disclose identified system incidents that were the result of controls that were not suitably designed or did not operate effectively, or that otherwise resulted in a significant failure to achieve a service commitment or system requirement. A service organization that suffered a reportable incident during the period and omitted it from Section III has produced a description that is not fairly presented, independently of whether the controls themselves were effective.

The Report's Sections

---

3. System Boundaries

The blueprint requires "clear identification of the boundaries of the system as defined by the service organization." Boundaries are management's declaration of what is in scope, and everything the opinion says is bounded by them.

A boundary statement should be explicit along several dimensions:

• Services and products. Which offering — and which editions or tiers — are covered.
• Infrastructure and locations. Which environments, regions and data centers; which are excluded.
• Applications and supporting systems. The corporate network and general-purpose IT are frequently excluded from a product-focused SOC 2 and must be named as such.
• Data. Which data types and flows are in scope.
• People and processes. Which teams and functions operate the in-scope controls.
• Subservice organizations. Named, with the carve-out or inclusive treatment stated.
• Time. The as-of date for a Type 1 or the period for a Type 2.

Why the auditor scrutinizes boundaries. A boundary drawn too narrowly produces a technically accurate report that misleads. A report scoped to one data center while the user entity's data is processed in another is useless to that user entity even though the opinion is unmodified. A report that excludes the corporate identity provider while the in-scope application authenticates against it has excluded the control that actually governs access.

What the user auditor does with them. The user auditor's first procedure on receiving a SOC report is to confirm that the boundaries and the period cover the services the user entity actually consumes during the audit period. Scope misalignment, not an adverse opinion, is the most common reason a SOC report turns out to be unusable.

---

4. Procedures Over Incident and Complaint Reporting Channels

A discrete blueprint task asks the candidate to "perform procedures to obtain an understanding of how a service organization provides its personnel and external users information on how to report failures, incidents, concerns and other complaints related to a system subject to a SOC 2 engagement." This maps to the Common Criteria on communication — internal communication to personnel and external communication with user entities and other parties — and, for privacy engagements, to the P8.0 monitoring and enforcement criteria.

Procedures to Perform

1. Inspect the channels themselves. Confirm that a documented mechanism exists for each audience: for personnel, a service desk, a security reporting mailbox, and an anonymous ethics or whistleblower line; for external users, a support portal, a published contact, a status page, and a security or vulnerability disclosure contact.
2. Verify the information is actually communicated. Inspect the onboarding materials, intranet page, acceptable use policy and awareness training for personnel; inspect the customer-facing terms, support documentation and website for external users. A channel nobody knows about is not a channel — this is the most common finding.
3. Test the channel end to end. Trace a sample of reported incidents, concerns and complaints from receipt through triage, assignment, resolution and communication back to the reporter, confirming that the population of reports is complete and that service levels were met.
4. Evaluate the anonymous route. Confirm that personnel can raise a concern about a superior without identifying themselves, and that a documented non-retaliation commitment exists and has been communicated.
5. Confirm escalation to the incident response process. A report that arrives at the service desk and is closed as a ticket without ever reaching the security function is a control breakdown; test that the routing criteria exist and were applied.
6. Confirm feedback loops. Complaints and reported failures should feed the risk assessment, the problem management process, and, where relevant, customer notification obligations.

---

5. Comparing Management's Description to the Criteria

The blueprint's Application-level task is to prepare a comparison of the description to the criteria — suitable criteria in a SOC 1, the description criteria in a SOC 2. Practically this is a mapping workpaper.

The Method

1. Build the grid. One row per description criterion. Columns: the criterion, the section and page of the description that addresses it, the evidence corroborating the disclosure, and the auditor's conclusion.
2. For each criterion, ask three questions in order.
   • Is it addressed at all? An omitted criterion is a straightforward failure of fair presentation.
   • Is the disclosure accurate? Corroborate against what the auditor observed while obtaining an understanding of the system — configurations, walkthroughs, org charts, contracts.
   • Is it complete enough for a user? Text that is technically true but so vague that a reader cannot evaluate relevance fails the criterion.
3. Test for what is missing rather than reading only what is present. The failures that matter are usually omissions: an undisclosed subservice organization, a system incident left out, CUECs the controls actually depend on but the description never states, a data center outside the stated boundary.
4. Check internal consistency. The controls listed in Section III must be the controls tested in Section IV; the boundaries in the description must match the scope in the assertion and the opinion; the period must be identical across all sections.
5. Conclude. Deficiencies in fair presentation are evaluated for materiality exactly as control deficiencies are — a material but non-pervasive failure of fair presentation supports a qualified opinion, and a pervasive one, or a description that is materially misleading, supports an adverse opinion.

The point candidates miss: the opinion on fair presentation of the description is separate from the opinion on controls. A service organization can have controls that were suitably designed and operated flawlessly and still receive a modified opinion because its description omitted a subservice organization, failed to disclose a system incident, or described a system that does not match the one the auditor examined.