Service Commitments
Customer, the organization, and relevant third-party responsibilities are documented for security, availability, data handling, integrations, monitoring, support, and response.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Customers, the company, and relevant third parties can tell which security and service responsibilities belong to each party, when those responsibilities apply, and how failure to perform them affects the service.
First SOC 2 program
Create a plain-language responsibility table for the main service covering account configuration, identity, data handling, integrations, monitoring, support, incident response, and recovery. Publish it during contracting or onboarding and link each responsibility to practical instructions.
As the company scales
Maintain product- and architecture-specific responsibility matrices, connect them to contracts and customer enablement, and require review when features, integrations, infrastructure providers, or operating boundaries change.
Diagram the systems, data flows, customer-managed components, integrations, and external providers that participate in delivering the service.
You should end up with: A current service-boundary diagram that identifies each participating party.
List the actions needed to secure, operate, monitor, recover, and support the service, including configuration and incident-coordination duties.
You should end up with: An actionable inventory of responsibilities rather than broad statements of intent.
Mark each action as owned by the company, customer, third party, or jointly owned, and state timing, prerequisites, and handoff points.
You should end up with: A responsibility matrix with clear owners and no unexplained gaps or overlaps.
Ask product, engineering, support, security, legal, and customer-facing teams to confirm that the documented boundary matches actual system behavior and commitments.
You should end up with: Dated cross-functional approval and a record of resolved discrepancies.
Connect customer-owned responsibilities to setup instructions, configuration checks, notification routes, and support contacts at the point where action is required.
You should end up with: Published onboarding and operating guidance linked to the responsibility matrix.
Assess the matrix when features, integrations, hosting models, external providers, or commitments change and communicate material changes to affected customers.
You should end up with: Version history, approvals, and customer communication records for material boundary changes.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Security, availability, data-handling, integration, monitoring, support, and response actions are allocated between the company, customer, and relevant third parties with usable handoffs.
Include this context
service or product scope
Include this context
responsibility and required action
Include this context
responsible party
Include this context
timing or trigger
Include this context
handoff or verification method
Include this context
version and approval date
Weak evidence to avoid
A two-column chart saying customer secures its environment and company secures the platform without actionable duties, timing, product scope, or handoff details.
Confirm what the record proves
Complementary user-entity and subservice-organization controls relevant to the service are identified, translated into actionable responsibilities, and connected to assurance dependencies.
Include this context
source report and period
Include this context
complementary control reference
Include this context
applicable service or customer
Include this context
responsible party
Include this context
implementation or monitoring method
Weak evidence to avoid
A copied list of complementary controls from a provider report with no applicability decision, responsible party, implementation status, or link to the affected service.
Confirm what the record proves
Customers receive practical instructions for the configurations and operating actions they must perform to use the service securely and reliably.
Include this context
product and version scope
Include this context
customer action
Include this context
prerequisite and timing
Include this context
configuration or verification steps
Include this context
support route
Weak evidence to avoid
A launch guide that recommends following best practices but gives no concrete identity settings, integration checks, monitoring action, or support contact.
Confirm what the record proves
Responsibility information is delivered at the point customers configure the service, and onboarding activity directs them to required security and support actions.
Include this context
customer and service
Include this context
material version
Include this context
delivery or session date
Include this context
responsibilities covered
Include this context
recipient or attendee
Include this context
open customer actions
Weak evidence to avoid
A welcome email with a general documentation link but no record of the security responsibilities presented, recipient, version, or unresolved setup actions.
Type 1
The current approved shared responsibility and complementary-control matrices, current customer implementation guidance, and one recent onboarding package as of the examination date.
Type 2
All customer onboardings completed during the review period and all shared-responsibility documents changed, approved, or communicated during the period, including product- or architecture-specific variants.
Reconcile customer-success onboarding records to delivered responsibility materials, and reconcile current product architecture and relevant provider complementary controls to the documented responsibility matrices, resolving missing parties or duties.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Customers, the company, and relevant third parties can tell which security and service responsibilities belong to each party, when those responsibilities apply, and how failure to perform them affects the service.
Compare the documented owner with the intended role (Service Owner / Legal / CISO), then compare dated records with the stated cadence: Ongoing; review at least annually.
Reconcile customer-success onboarding records to delivered responsibility materials, and reconcile current product architecture and relevant provider complementary controls to the documented responsibility matrices, resolving missing parties or duties.
The current approved shared responsibility and complementary-control matrices, current customer implementation guidance, and one recent onboarding package as of the examination date.
All customer onboardings completed during the review period and all shared-responsibility documents changed, approved, or communicated during the period, including product- or architecture-specific variants.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Security, availability, data-handling, integration, monitoring, support, and response actions are allocated between the company, customer, and relevant third parties with usable handoffs.
For each selected record, confirm it demonstrates Complementary user-entity and subservice-organization controls relevant to the service are identified, translated into actionable responsibilities, and connected to assurance dependencies.
For each selected record, confirm it demonstrates Customers receive practical instructions for the configurations and operating actions they must perform to use the service securely and reliably.
For each selected record, confirm it demonstrates Responsibility information is delivered at the point customers configure the service, and onboarding activity directs them to required security and support actions.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.