Service Commitments
New or changed customer-facing commitments are reviewed by business, legal, security, engineering, and service owners before external use.
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
New or changed customer commitments are checked by the people who understand the legal, security, product, engineering, and service implications before the company relies on or publishes them.
First SOC 2 program
Use a single deal or content-review ticket that includes the exact proposed wording and approval from the relevant business, legal, security, and technical owners. Reserve deeper review for promises that differ from the company’s approved position.
As the company scales
Embed risk-based approval paths into contract, sales, and publishing systems, automatically route nonstandard promises to subject-matter owners, and transfer approved obligations into the commitment register and operational backlog.
Open a review record containing the proposed language, source document, customer or audience, due date, affected service, and request owner.
You should end up with: A dated intake record tied to the exact version under review.
Compare the wording with approved company positions and flag new guarantees, tighter timelines, broader scope, unusual remedies, or claims that depend on future work.
You should end up with: A marked review record showing standard and nonstandard commitments.
Send each material statement to the functions able to validate it, including service, engineering, security, privacy, legal, support, or finance as applicable.
You should end up with: Named approvals, requested changes, or rejection from the necessary subject-matter owners.
Revise unsupported wording, document an approved exception, or complete the required operational work before the commitment is signed or published.
You should end up with: A final disposition with resolved comments and links to any prerequisite work.
Confirm that the approved language is the same version used externally and preserve the final document and approval trail.
You should end up with: A final version linked to dated approvals and the external-use record.
Add the approved commitment to the register, notify the operational owner, and create any monitoring, reporting, or delivery tasks needed to fulfill it.
You should end up with: A commitment record linked to an owner, supporting control, and any required operational action.
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
Proposed customer commitments are routed to the business, legal, security, engineering, and service reviewers needed for the specific wording before external use.
Include this context
request and document identifier
Include this context
exact version reviewed
Include this context
required reviewer roles
Include this context
review decisions and timestamps
Include this context
final disposition
Weak evidence to avoid
A deal ticket marked approved by Sales Ops with no attached wording, technical reviewer, legal decision, timestamps, or link to the final customer version.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Material security and service assertions in customer questionnaires or bid responses were checked against current company capabilities before submission.
Include this context
customer and response identifier
Include this context
response version
Include this context
material assertions flagged
Include this context
subject owner reviewer
Include this context
review date and disposition
Weak evidence to avoid
A submitted response file with broad encryption and availability claims but no reviewer comments, approval trail, or evidence that the final answers were validated.
Confirm what the record proves
Reviewers identified and resolved nonstandard security, availability, support, data, or delivery obligations in the relevant contract or statement of work.
Include this context
agreement and customer
Include this context
clause or obligation reviewed
Include this context
reviewer and function
Include this context
comment or requested change
Include this context
resolution and final location
Weak evidence to avoid
A comment stating looks fine on an early agreement draft without the clauses considered, reviewer function, resolved wording, or final signed document.
Confirm what the record proves
Authorized security and legal reviewers accepted the final material commitment language, including any deviation and its rationale, before it was used.
Include this context
document and final version
Include this context
security approver
Include this context
legal approver
Include this context
approval timestamp
Include this context
conditions or accepted deviations
Weak evidence to avoid
Two approval emojis in chat with no document link, version, approver identity, decision date, or record of an accepted nonstandard obligation.
Type 1
The configured commitment-approval workflow, reviewer decision rules, approved standard positions, and one recent completed approval showing final-version control as of the examination date.
Type 2
Every customer-facing contract, statement of work, questionnaire or bid response, service description, and assurance-content change submitted for commitment review during the review period, including rejected and withdrawn requests.
Reconcile submitted sales assurance responses and executed or published customer content to approval records, then compare initial and final versions for a sample to confirm the approved wording is the wording used externally.
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: New or changed customer commitments are checked by the people who understand the legal, security, product, engineering, and service implications before the company relies on or publishes them.
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 submitted sales assurance responses and executed or published customer content to approval records, then compare initial and final versions for a sample to confirm the approved wording is the wording used externally.
The configured commitment-approval workflow, reviewer decision rules, approved standard positions, and one recent completed approval showing final-version control as of the examination date.
Every customer-facing contract, statement of work, questionnaire or bid response, service description, and assurance-content change submitted for commitment review during the review period, including rejected and withdrawn requests.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Proposed customer commitments are routed to the business, legal, security, engineering, and service reviewers needed for the specific wording before external use.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Material security and service assertions in customer questionnaires or bid responses were checked against current company capabilities before submission.
For each selected record, confirm it demonstrates Reviewers identified and resolved nonstandard security, availability, support, data, or delivery obligations in the relevant contract or statement of work.
For each selected record, confirm it demonstrates Authorized security and legal reviewers accepted the final material commitment language, including any deviation and its rationale, before it was used.
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.