Service Commitments
Commitment exceptions, deviations, unsupported customer assumptions, and service limitations are documented, approved, and tracked.
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
Departures from commitments and unsupported customer assumptions are visible, explicitly approved at the right level, bounded in time, and either corrected or knowingly accepted with safeguards.
First SOC 2 program
Use one exception register. Require every deviation to name the affected commitment, service or customer, business reason, risk, compensating measure, owner, approver, and expiration date before the company proceeds.
As the company scales
Route exceptions through a governance platform using risk-based approval levels, automated expiration reminders, links to customer and service records, periodic management reporting, and independent validation before closure.
Set intake criteria for unmet commitments, policy deviations, unsupported customer assumptions, service limitations, missed obligations, and approved temporary workarounds.
You should end up with: Published exception criteria and clear intake ownership.
Record the affected commitment, expected behavior, actual condition, scope, affected customer or service, start date, and requested duration.
You should end up with: A complete exception record linked to the relevant commitment and source facts.
Evaluate security, availability, legal, privacy, operational, and customer consequences using current technical and contractual information.
You should end up with: A documented risk assessment with affected parties and residual risk.
Define compensating measures, monitoring, restrictions, remediation work, accountable owners, milestones, and an expiration or review date.
You should end up with: A time-bounded action plan linked to operating evidence and monitoring results.
Route the decision to a leader with authority over the affected risk and customer obligation, escalating material exceptions to executive or legal review as appropriate.
You should end up with: A dated approval, rejection, or required revision with stated rationale.
Review open items before expiration, escalate overdue remediation, and close only after the expected condition is restored or a new documented decision is approved.
You should end up with: Review history and closure evidence, or a separately approved renewal with updated facts.
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
Temporary safeguards address the stated risk during the exception, have assigned operators and monitoring, and remain in place until remediation or expiry.
Include this context
exception identifier
Include this context
safeguard and risk addressed
Include this context
operator
Include this context
operating frequency
Include this context
monitoring evidence
Include this context
effective and end dates
Weak evidence to avoid
A note promising increased monitoring without naming the signal, threshold, operator, review frequency, evidence location, or end date.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Commitment deviations and service limitations are centrally visible with exact scope, affected promise, risk, safeguards, approval, ownership, and expiration.
Include this context
exception identifier
Include this context
affected commitment and scope
Include this context
actual deviation and business reason
Include this context
owner and approver
Include this context
start and expiration dates
Include this context
status and action link
Weak evidence to avoid
A row labeled customer exception approved with no affected promise, customer scope, deviation, owner, risk, approval evidence, or expiration.
Confirm what the record proves
A leader with appropriate authority knowingly accepted the documented residual security, service, legal, and customer impact for a defined period.
Include this context
exception and risk identifier
Include this context
risk and customer impact
Include this context
residual risk rationale
Include this context
decision authority
Include this context
approval date
Include this context
expiration or review date
Weak evidence to avoid
A business owner writes risk accepted in a ticket without quantified impact, technical or legal input, approval authority, review date, or affected-customer scope.
Type 1
The current exception and risk-acceptance procedure, open exception register, approval authorities, and evidence that compensating safeguards for current exceptions are operating as of the examination date.
Type 2
Every commitment exception, unsupported customer assumption, service limitation, risk acceptance, renewal, expiration, or closure active or processed at any time during the review period.
Reconcile commitment and control deviations in issue, contract, and service records to the exception register; then compare expiration dates to review, renewal, or closure records and verify safeguard evidence throughout each active interval.
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: Departures from commitments and unsupported customer assumptions are visible, explicitly approved at the right level, bounded in time, and either corrected or knowingly accepted with safeguards.
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 commitment and control deviations in issue, contract, and service records to the exception register; then compare expiration dates to review, renewal, or closure records and verify safeguard evidence throughout each active interval.
The current exception and risk-acceptance procedure, open exception register, approval authorities, and evidence that compensating safeguards for current exceptions are operating as of the examination date.
Every commitment exception, unsupported customer assumption, service limitation, risk acceptance, renewal, expiration, or closure active or processed at any time during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Temporary safeguards address the stated risk during the exception, have assigned operators and monitoring, and remain in place until remediation or expiry.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Commitment deviations and service limitations are centrally visible with exact scope, affected promise, risk, safeguards, approval, ownership, and expiration.
For each selected record, confirm it demonstrates A leader with appropriate authority knowingly accepted the documented residual security, service, legal, and customer impact for a defined period.
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.