Service Commitments
Service descriptions, RFP responses, and assurance materials accurately describe implemented capabilities, limitations, dependencies, and customer obligations.
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
Customer-facing descriptions match the service that is actually operating, including its security capabilities, limitations, dependencies, and customer obligations.
First SOC 2 program
Keep an approved set of service facts covering architecture, security, availability, support, data handling, and known limitations. Require a technical and security owner to review material external claims before they are published or sent to a customer.
As the company scales
Establish an authoritative service-content library, assign subject owners by claim type, and trigger coordinated review when product releases, architecture changes, incidents, provider changes, or new commitments could make published information inaccurate.
Identify trust-center content, service descriptions, sales assurance material, security questionnaire responses, product documentation, and other statements customers rely on.
You should end up with: A content inventory with owner, audience, location, current version, and last review date.
Document approved facts for important claims such as encryption, access controls, backups, monitoring, support, data location, and external dependencies.
You should end up with: A controlled fact set linked to the systems or processes that support each statement.
Have the people who run the service confirm that claims describe current capability and preserve qualifications, exclusions, product differences, and customer responsibilities.
You should end up with: Dated subject-owner review with corrections and resolved questions.
Route material new or changed statements through service, security, legal, and other relevant reviewers, then lock the approved version for publication.
You should end up with: An approval trail connected to the exact content version used externally.
Connect release, architecture, incident, vendor, and contractual-change processes to a content impact check so affected descriptions are updated promptly.
You should end up with: Change records showing which content was reviewed and what was updated or confirmed unchanged.
Sample important claims across customer-facing channels and compare them with each other and with the current operating environment.
You should end up with: A periodic accuracy review with discrepancies, owners, due dates, and completed corrections.
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
Published assurance claims about security, privacy, availability, and compliance reflect approved current facts and disclose relevant scope or limitations.
Include this context
page or claim identifier
Include this context
published content and version
Include this context
service scope
Include this context
subject owner
Include this context
approval and publication dates
Include this context
supporting fact or system
Weak evidence to avoid
A trust-center page claiming all data is encrypted everywhere with no service scope, qualification, technical owner, approval date, or supporting configuration reference.
Confirm what the record proves
Formal descriptions accurately present the implemented service, system boundary, capabilities, dependencies, limitations, and customer responsibilities for the stated period.
Include this context
service and boundary
Include this context
description version and date
Include this context
capabilities and limitations
Include this context
key dependencies
Include this context
customer responsibilities
Include this context
owner approval
Weak evidence to avoid
A service description that names the product but omits hosting dependencies, excluded components, customer-managed integrations, limitations, and approval history.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Customer-specific security answers were based on current company capabilities, reviewed by knowledgeable owners, and retained in the version delivered.
Include this context
customer and questionnaire identifier
Include this context
response version
Include this context
material answer or claim
Include this context
subject owner and review date
Include this context
final delivery date
Weak evidence to avoid
A completed questionnaire copied from an older deal with no evidence that answers were checked for the current product, architecture, or delivery version.
Confirm what the record proves
The exact customer-facing content received the required service, technical, security, and legal review before publication or delivery.
Include this context
content identifier and version
Include this context
required reviewer roles
Include this context
reviewer decisions
Include this context
approval timestamps
Include this context
publication or delivery status
Weak evidence to avoid
A ticket approved before the final edits with no record that reviewers saw the version later published to customers.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Material changes to service claims are traceable to the triggering product or operating change, review, approval, and publication event.
Include this context
content identifier
Include this context
prior and new version
Include this context
triggering change
Include this context
change summary
Include this context
editor and approver
Include this context
effective date
Weak evidence to avoid
A live webpage with a recent updated date but no prior version, change summary, triggering release, or person who approved the revision.
Type 1
Current approved trust-center content, security answer source material, service description, content-review procedure, and the latest completed approval and change history as of the examination date.
Type 2
All trust-center, service-description, security-questionnaire, and assurance-content items newly published, delivered, or materially changed during the review period, plus all periodic accuracy reviews due in the period.
Reconcile externally available trust and service content plus delivered questionnaire records to approval history, then reconcile material product and architecture changes to recorded content-impact decisions.
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: Customer-facing descriptions match the service that is actually operating, including its security capabilities, limitations, dependencies, and customer obligations.
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 externally available trust and service content plus delivered questionnaire records to approval history, then reconcile material product and architecture changes to recorded content-impact decisions.
Current approved trust-center content, security answer source material, service description, content-review procedure, and the latest completed approval and change history as of the examination date.
All trust-center, service-description, security-questionnaire, and assurance-content items newly published, delivered, or materially changed during the review period, plus all periodic accuracy reviews due in the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Published assurance claims about security, privacy, availability, and compliance reflect approved current facts and disclose relevant scope or limitations.
For each selected record, confirm it demonstrates Formal descriptions accurately present the implemented service, system boundary, capabilities, dependencies, limitations, and customer responsibilities for the stated period.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Customer-specific security answers were based on current company capabilities, reviewed by knowledgeable owners, and retained in the version delivered.
For each selected record, confirm it demonstrates The exact customer-facing content received the required service, technical, security, and legal review before publication or delivery.
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 changes to service claims are traceable to the triggering product or operating change, review, approval, and publication event.
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.