Service Commitments
Customer-facing commitments are maintained in an approved register with owner, source, control mapping, applicability, review status, and evidence location.
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 exactly what it has promised customers, where each promise originated, who owns it, which services it applies to, and how the promise is supported in practice.
First SOC 2 program
Start with a single commitment register. Review signed agreements, service-level terms, data-processing terms, security statements, and other customer-facing assurance content, then record each meaningful obligation with an owner and link to supporting operations.
As the company scales
Connect contract review, sales assurance, product change, and compliance workflows so new or changed commitments enter the register automatically and receive periodic owner attestation against current service capabilities.
Identify the customer-facing documents and approved statements that can create security, availability, confidentiality, privacy, support, or notification obligations.
You should end up with: A source inventory linked to current executed or published versions.
Translate each relevant promise into a concise obligation while preserving its exact source, effective date, customer or product scope, and any conditions or exclusions.
You should end up with: Individual commitment records that can be filtered by source, service, and customer applicability.
Name the service, legal, security, or engineering owner responsible for keeping each commitment accurate and achievable.
You should end up with: A register with no active commitment lacking an accountable owner.
Link each promise to the process, control, system, metric, or third-party dependency that supports it, and flag promises that are not yet fully supported.
You should end up with: A documented mapping from commitment to supporting operation and evidence location.
Have the operational owner confirm that the wording matches current capability, including limitations, shared responsibilities, product editions, and customer-specific terms.
You should end up with: Dated owner review records and documented corrections or accepted exceptions.
Trigger review when contracts renew, assurance content changes, products launch, dependencies change, or incidents reveal a mismatch, and perform a periodic completeness review.
You should end up with: Change history and periodic review records showing additions, updates, and retired commitments.
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
Material customer-facing security and service promises are centrally identified with their source, scope, owner, applicability, operational support, and current review status.
Include this context
commitment identifier and text
Include this context
source and effective version
Include this context
customer or service applicability
Include this context
accountable owner
Include this context
review status and date
Include this context
supporting operation or evidence link
Weak evidence to avoid
A list of contract filenames that does not extract the actual promises, identify affected customers, assign owners, or link each promise to an operating process.
Confirm what the record proves
Each commitment is connected to the specific control, process, metric, or system relied upon to fulfill and monitor it.
Include this context
commitment identifier
Include this context
control or process identifier
Include this context
relationship rationale
Include this context
operational owner
Include this context
evidence location
Weak evidence to avoid
Every customer promise is mapped only to Security Program with no specific control, system, rationale, owner, or operating evidence.
Confirm what the record proves
The register entries can be traced to the executed or published customer-facing language, including conditions, exclusions, dates, and scope.
Include this context
document title and type
Include this context
customer or audience
Include this context
executed or published version
Include this context
effective date
Include this context
commitment location or section
Weak evidence to avoid
An editable sales document with no customer, final-version status, effective date, or section reference supporting the registered obligation.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Commitment owners periodically confirmed completeness, applicability, and continued operational support and resolved identified changes or mismatches.
Include this context
commitment or review population
Include this context
review date
Include this context
reviewer and owner
Include this context
changes considered
Include this context
decision and follow-up
Weak evidence to avoid
A note saying commitments reviewed with no population, owner attestations, changes considered, decisions, or linked corrections.
Type 1
The current commitment register with source documents and control mappings, plus the latest owner review showing the inventory is designed to capture and govern active promises as of the examination date.
Type 2
All commitments active at any time during the review period and all commitments added, changed, renewed, retired, or reviewed during the period, including customer-specific and generally published promises.
Reconcile the register to executed agreements, current service-level and data terms, published assurance content, and material customer-specific responses; investigate every source commitment without a register ID and every register entry without a valid source.
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 exactly what it has promised customers, where each promise originated, who owns it, which services it applies to, and how the promise is supported in practice.
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 the register to executed agreements, current service-level and data terms, published assurance content, and material customer-specific responses; investigate every source commitment without a register ID and every register entry without a valid source.
The current commitment register with source documents and control mappings, plus the latest owner review showing the inventory is designed to capture and govern active promises as of the examination date.
All commitments active at any time during the review period and all commitments added, changed, renewed, retired, or reviewed during the period, including customer-specific and generally published promises.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Material customer-facing security and service promises are centrally identified with their source, scope, owner, applicability, operational support, and current review status.
For each selected record, confirm it demonstrates Each commitment is connected to the specific control, process, metric, or system relied upon to fulfill and monitor it.
For each selected record, confirm it demonstrates The register entries can be traced to the executed or published customer-facing language, including conditions, exclusions, dates, and scope.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Commitment owners periodically confirmed completeness, applicability, and continued operational support and resolved identified changes or mismatches.
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.