SOC2-S1-SECURITY-COMMITMENTS
Security Commitments Documentation
What this control does
Published security commitments to customers and stakeholders, documented in contracts, SLAs, and public security documentation.
Implementation guidance
Publish a security and trust page documenting your encryption standards, access controls, incident notification SLAs, and compliance posture. Include security provisions in customer agreements (DPAs, MSAs). Review commitments annually against actual capability and update if gaps exist.
Requirements satisfied
Why it matters
Undocumented or inconsistent security commitments create legal exposure (contract disputes, regulatory fines) and operational risk when customer expectations diverge from actual capability. Competitors and customers evaluate your trustworthiness based on published commitments; misalignment between stated and real controls undermines credibility and enables audit failures during customer security assessments.
Evidence to collect
- Published security/trust page URL with screenshots showing encryption standards, access control architecture, and incident response SLA timelines
- Data Processing Agreement (DPA) or similar contract appendix signed by at least one customer, highlighting security obligations and incident notification terms
- Annual commitment review log or document (e.g., spreadsheet, change record) dated within last 12 months showing comparison of published commitments to current technical capabilities
- Incident notification SLA specification (in contract or policy) with minimum time-to-notify threshold for confirmed incidents
Testing procedure
Request the published security page and one customer DPA; verify encryption method, MFA requirement, backup/disaster recovery RTO/RPO, and breach notification timeline are explicitly stated. Trace one stated control (e.g., "AES-256 encryption in transit") to technical documentation or system configuration. Review the annual compliance review record to confirm commitments were evaluated against current architecture; flag any stated capabilities not actually implemented.
Common gotchas
Many organizations publish a generic security page but fail to bind it contractually—customers later dispute incident response obligations because terms were not in the signed agreement. Equally common: security pages lag behind infrastructure changes (e.g., still listing SOC 2 Type I expiry date, or claiming features that were disabled), creating a credibility gap that auditors and customers notice immediately.