Service Commitments
Material changes to commitments, responsibility boundaries, or service capabilities follow controlled review and customer notification requirements where applicable.
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
Material changes to the service, customer commitments, or responsibility boundaries are reviewed before release and customers receive required notice through a controlled, traceable process.
First SOC 2 program
Add a customer-impact question to the release and contract-change process. For a material change, have the service owner, security lead, and legal owner decide whether notice is required, approve the message, and retain proof of when and how it was sent.
As the company scales
Use risk-based workflows that connect engineering changes, product launches, provider changes, legal obligations, customer segmentation, and communications, with explicit emergency-change follow-up and metrics for timely notice.
Set criteria for changes that may alter security, availability, data use, hosting location, support, integrations, external providers, service functionality, or customer responsibilities.
You should end up with: Approved materiality criteria and examples available to change requesters.
Require proposed product, technical, contractual, and provider changes to identify affected services, customers, commitments, and planned release dates.
You should end up with: A change record with enough context to make a notification decision before implementation.
Have service, security, legal, privacy, support, and customer owners evaluate whether commitments, shared responsibilities, or notice obligations are affected.
You should end up with: A documented impact and notification decision with named reviewers.
Resolve required safeguards, update affected customer content, identify recipients, and approve the timing and wording of any notification before release.
You should end up with: A release approval linked to final customer communication and updated service content.
Send notice through the required channels and retain the final message, recipient population, timestamp, delivery status, and any customer follow-up.
You should end up with: A communication record showing what was sent, to whom, when, and with what result.
Allow an expedited path when delay would create greater risk, then require timely retrospective impact review, approval, content updates, and notice assessment.
You should end up with: An emergency-change record with post-implementation review and completed follow-up actions.
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.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Authorized reviewers considered applicable commitments and customer terms and decided whether, when, and how affected customers should be notified.
Include this context
change identifier
Include this context
affected customer population
Include this context
commitment or notice term considered
Include this context
decision and rationale
Include this context
reviewers
Include this context
required timing and channel
Weak evidence to avoid
A no notice needed checkbox with no affected-customer analysis, contractual basis, reviewer, rationale, or decision date.
Confirm what the record proves
The material change, updated responsibility or service content, and any customer message received accountable service, security, legal, or communication approval before release.
Include this context
change and content version
Include this context
required approvers
Include this context
approval decision
Include this context
approval timestamp
Include this context
conditions or deferred actions
Weak evidence to avoid
A release marked approved by the developer who made the change without service, security, or legal review of the customer-impact decision.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Material product, technical, provider, or contractual changes were captured early enough to assess effects on commitments, responsibility boundaries, and customer notice.
Include this context
change identifier and description
Include this context
affected service and customers
Include this context
planned and actual release date
Include this context
materiality assessment
Include this context
commitment impact decision
Include this context
change owner
Weak evidence to avoid
A deployment ticket stating database migration complete with no customer scope, materiality question, commitment impact, or notification decision.
Confirm what the record proves
The final released change and its effective timing are recorded and align with the change scope and customer communication that reviewers approved.
Include this context
release identifier and version
Include this context
change summary
Include this context
affected products
Include this context
release timestamp
Include this context
customer-visible impact
Include this context
communication link
Weak evidence to avoid
Release notes saying improvements and fixes with no product scope, release date, material customer impact, or link to the approved notification.
Type 1
Current material-change criteria, configured customer-impact review workflow, and current notification decision rules as of the examination date. Include an applicable current change record through materiality and notification decisions when one exists; if complete queries across product, infrastructure, external-provider, contract, and responsibility-boundary change sources return no applicable change, retain those zero-result queries and walkthrough a representative change through the configured review and notice path.
Type 2
All product, infrastructure, external-provider, contract, and responsibility-boundary changes created, approved, implemented, or rejected during the review period, including urgent changes, whether ultimately classified as material or not. Each change should carry its materiality and customer-notification decision, including decisions that no notice was required.
Start with the complete product-release, infrastructure-change, provider-change, contract-change, and responsibility-boundary-change populations from their authoritative systems, then reconcile every change to a documented materiality and notification decision. Trace each notify decision to recipient and delivery records and each urgent change to its retrospective review.
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: Material changes to the service, customer commitments, or responsibility boundaries are reviewed before release and customers receive required notice through a controlled, traceable process.
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.
Start with the complete product-release, infrastructure-change, provider-change, contract-change, and responsibility-boundary-change populations from their authoritative systems, then reconcile every change to a documented materiality and notification decision. Trace each notify decision to recipient and delivery records and each urgent change to its retrospective review.
Current material-change criteria, configured customer-impact review workflow, and current notification decision rules as of the examination date. Include an applicable current change record through materiality and notification decisions when one exists; if complete queries across product, infrastructure, external-provider, contract, and responsibility-boundary change sources return no applicable change, retain those zero-result queries and walkthrough a representative change through the configured review and notice path.
All product, infrastructure, external-provider, contract, and responsibility-boundary changes created, approved, implemented, or rejected during the review period, including urgent changes, whether ultimately classified as material or not. Each change should carry its materiality and customer-notification decision, including decisions that no notice was required.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Authorized reviewers considered applicable commitments and customer terms and decided whether, when, and how affected customers should be notified.
For each selected record, confirm it demonstrates The material change, updated responsibility or service content, and any customer message received accountable service, security, legal, or communication approval before release.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Material product, technical, provider, or contractual changes were captured early enough to assess effects on commitments, responsibility boundaries, and customer notice.
For each selected record, confirm it demonstrates The final released change and its effective timing are recorded and align with the change scope and customer communication that reviewers approved.
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.