Framework

Origin & evolution

The named frameworks arrived from different lineages. SOC 2 grew out of the AICPA's audit standards; its current shape, the 2017 Trust Services Criteria, organises controls around security, availability, processing integrity, confidentiality, and privacy. ISO/IEC 27001 was first published in 2005 and revised in 2013 and 2022, defining an information-security management system rather than a fixed checklist. The GDPR was adopted in 2016 and became enforceable on 25 May 2018, turning data protection into a legal regime with real penalties.

What unites them is the certification🏵️CertificationCustomer EducationA certification programView reference → cycle: a product declares scope, implements controls, and submits to a periodic audit that issues a report or certificate with an expiry. The framework is a standing commitment, renewed on a clock.

How it works in practice

A B2B SaaS company commits to SOC 2 Type II to close enterprise deals. The framework expands into roughly sixty individual requirements covering access control, change management, and incident🚨IncidentDevOps & PlatformA production incidentView reference → response. Over a three-month observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference → window, an external auditor samples evidence for each. One requirement (quarterly access reviews) has a gap: two reviews were skipped. The auditor notes the exception, the company remediates, and the next cycle clears it. The framework holds; the requirement was the thing that moved.

Compliance Framework vs. its neighbours

• Compliance Requirement⛲Compliance RequirementComplianceA compliance requirementView reference → is one mandated control derived from the framework. The framework is the named regime; the requirement is a single line item it demands. One framework spawns dozens of requirements.
• Security Audit🛃Security AuditComplianceA security auditView reference → is the act of verifying the framework is met. The framework defines what good looks like; the audit checks whether reality matches, and produces the evidence.
• Risk🎲RiskComplianceA risk to the product or businessView reference → is what the framework exists to reduce. A framework is a structured response to a class of risks, so the two are connected but distinct: the risk is the threat☠️ThreatSecurityA specific security threatView reference →, the framework is the managed answer.

In the graph

In the Unified Product Graph, a compliance framework anchors the governance and compliance region. A product commits through product_governed_by_compliance_frameworkProductgoverned byCompliance Frameworkhierarchy; the framework expands via compliance_framework_mandates_compliance_requirementCompliance FrameworkmandatesCompliance Requirementhierarchy, is checked by compliance_framework_verified_by_security_auditCompliance Frameworkverified bySecurity Audithierarchy, and triggers documentation through compliance_framework_requires_privacy_policyCompliance FrameworkrequiresPrivacy Policyhierarchy. Separating the regime from its requirements and its audits keeps the structure honest: a framework with no verified requirements is visibly a claim without proof.