Service Commitments
Dependencies required to meet commitments are identified, assigned owners, monitored, and linked to supporting controls and procedures.
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
The company knows which people, systems, vendors, integrations, and operating processes are necessary to meet each material customer commitment and manages the risk of their failure.
First SOC 2 program
For each important service promise, draw the delivery chain from customer request to supporting infrastructure and external provider. Name an owner for every critical dependency and record the monitoring signal, fallback, and escalation route.
As the company scales
Maintain a service catalog that connects commitments to architecture, critical vendors, operating teams, health indicators, continuity plans, and control owners, with automated review triggers from system and provider changes.
Select the security, availability, support, data-handling, and recovery promises whose failure could materially affect customers.
You should end up with: A prioritized list of commitments to trace through the service.
Identify the applications, infrastructure, external providers, data flows, integrations, people, and procedures required to fulfill each selected commitment.
You should end up with: A dependency map linking each commitment to the components that support it.
Evaluate the customer impact, recovery difficulty, substitutability, concentration, and control reliance associated with each dependency.
You should end up with: A criticality rating with documented rationale and identified single points of failure.
Name an accountable owner and define how availability, security, capacity, contract status, or other relevant health will be monitored.
You should end up with: Dependency records with owners, health indicators, thresholds, and escalation paths.
Document fallback, recovery, workaround, or risk-acceptance decisions for critical dependencies and verify that the response aligns with customer expectations.
You should end up with: Linked continuity actions, recovery procedures, or approved residual-risk decisions.
Update dependency records after material service changes, vendor changes, incidents, resilience exercises, and periodic owner reviews.
You should end up with: Dated reviews and change history showing that the map reflects the current service.
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
Critical internal and external dependencies are linked to the commitments they support, their owners, failure impact, monitoring, and continuity treatment.
Include this context
dependency identifier and type
Include this context
supported service or commitment
Include this context
criticality and rationale
Include this context
accountable owner
Include this context
health signal and threshold
Include this context
fallback or risk decision
Weak evidence to avoid
A list of cloud products with no supported commitment, internal dependency, owner, criticality, monitoring threshold, or disruption response.
Confirm what the record proves
External providers required for service delivery are identified with their service role, customer impact, risk tier, contract status, and responsible relationship owner.
Include this context
vendor and service
Include this context
dependent product or process
Include this context
customer impact
Include this context
risk tier
Include this context
business owner
Include this context
contract and review status
Weak evidence to avoid
A procurement export that lists vendor names and annual spend but not which service depends on them or the impact if they fail.
Confirm what the record proves
Named operational owners accept responsibility for monitoring each critical dependency, escalating degradation, and maintaining the planned response.
Include this context
service and dependency
Include this context
primary owner
Include this context
backup owner
Include this context
monitoring responsibility
Include this context
escalation responsibility
Include this context
assignment review date
Weak evidence to avoid
An architecture diagram labeling Engineering as owner without a named role, backup, monitoring duty, escalation duty, or review date.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Defined dependency health signals were observed and material threshold breaches were investigated, escalated, and connected to service impact.
Include this context
dependency and signal
Include this context
observation period
Include this context
threshold
Include this context
breach timestamp
Include this context
reviewer or responder
Include this context
disposition and linked incident
Weak evidence to avoid
A current green dashboard screenshot with no historical period, threshold definition, dependency identity, or record of how prior alerts were handled.
Type 1
The current approved dependency register, service and vendor mappings, owner assignments, monitoring configuration, and continuity decisions for critical dependencies as of the examination date.
Type 2
All dependencies designated critical or high during the review period, all periodic owner reviews due for those dependencies, and every recorded health-threshold breach or material dependency change during the period.
Reconcile critical components in service architecture and the vendor inventory to the dependency register, then reconcile monitoring threshold breaches to incident or documented disposition records.
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: The company knows which people, systems, vendors, integrations, and operating processes are necessary to meet each material customer commitment and manages the risk of their failure.
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 critical components in service architecture and the vendor inventory to the dependency register, then reconcile monitoring threshold breaches to incident or documented disposition records.
The current approved dependency register, service and vendor mappings, owner assignments, monitoring configuration, and continuity decisions for critical dependencies as of the examination date.
All dependencies designated critical or high during the review period, all periodic owner reviews due for those dependencies, and every recorded health-threshold breach or material dependency change during the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Critical internal and external dependencies are linked to the commitments they support, their owners, failure impact, monitoring, and continuity treatment.
For each selected record, confirm it demonstrates External providers required for service delivery are identified with their service role, customer impact, risk tier, contract status, and responsible relationship owner.
For each selected record, confirm it demonstrates Named operational owners accept responsibility for monitoring each critical dependency, escalating degradation, and maintaining the planned response.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Defined dependency health signals were observed and material threshold breaches were investigated, escalated, and connected to service impact.
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.