Foreword
This standard began with practitioners, not committees. It comes out of two decades of watching the same problem repeat. Teams build, ship, and grow faster than their ability to prove they are operating safely, then scramble manually when a customer, regulator, or auditor finally asks for proof. SocOps is the continuous operating layer beneath the frameworks: the daily discipline that turns compliance from an annual event into an operating state.
It is published openly, as a validation draft, so the people who do this work can test it and tell us where it falls apart.
The Manifesto
We have come to value:
- Continuous readiness over the annual scramble.
- Evidence as a byproduct of work over evidence gathered for audits.
- Governed speed over uncontrolled velocity.
- Shared accountability over siloed ownership.
- Trust built in over trust claimed.
- Practical adoption over framework complexity.
- Portable operating discipline over tool-dependent compliance.
Why SocOps exists
Controls operate every day; audits happen once a year. The gap between those two facts is where trust quietly fails. It shows up as the spreadsheet trap, screenshot audits, control drift, and audit panic. A new generation of builders now ships production software in days using AI agents and third-party APIs, long before anyone writes a policy. SocOps names that gap and gives teams a way to close it continuously.
What it is, and what it is not
The governing rule: SocOps does not perform specialist security, compliance, engineering, audit, or legal work. It defines the operating discipline by which the outputs of those practices become owned, prioritized, evidenced, monitored for drift, and continuously sustained.
It is not a replacement for SOC 2, ISO 27001, HIPAA, NIST, CMMC, FedRAMP, or PCI. It is not an audit opinion or attestation, not legal or accounting advice, and not a tool, scanner, or platform.
Core principles
- Compliance is continuous, not annual.
- Evidence is a direct byproduct of operations.
- Controls must be monitored for drift.
- AI systems require adaptive governance.
- Human accountability must remain clear.
- Automation must be transparent and explainable.
- Risk decisions must be defensible and traceable.
- Controls must map broadly across frameworks.
- Remediation must be timely and measurable.
- Governance should enable speed, not block it.
The seven operating models
Seven models translate the discipline into practice. Each opens with what SocOps does not do, then defines what it owns.
- Evidence. Documentation is not evidence. Evidence is a verifiable record that a control actually operated.
- Drift. The widening gap between attested and live state, detected and remediated continuously.
- Vulnerability Operations. A scanner finding is not remediation; findings are owned, dispositioned, and verified.
- Policy and Obligation Alignment. Keep obligation, policy, control, owner, and evidence in one aligned chain.
- Environment and Data Boundary. Production data stays out of non-production unless authorized and evidenced.
- Release and Change Readiness. A risk-proportionate record that a release was reviewed, approved, and evidenced.
- Operating Cadence Alignment. Make readiness visible inside the rhythm the organization already runs.
AI governance
AI is part of the operating environment and is governed continuously. Inventory AI systems, agents, and external model APIs, including shadow AI. Classify them by data sensitivity and consequence. Require named human ownership for high-consequence actions, and ensure AI-driven actions produce traceable, explainable records.
Framework-agnostic control objectives
The standard defines what good looks like as control objectives that map broadly across frameworks, stopping at the objective level: governance and accountability, access and identity, change and configuration, data protection and privacy, environment boundaries, vulnerability operations, policy alignment, release readiness, logging and evidence, vendor and supply chain, AI and automation, operating cadence, and drift and remediation.
Roles and accountability
SocOps does not require new hires or titles. What matters is that responsibilities are named and owned. Developers, security and InfoSec, DevOps and platform, GRC and internal audit, legal and privacy, CPA advisors, and executives all operate from one shared view of readiness.
Independence and separation of duties
Advisory and implementation work must remain strictly separate from independent attestation. SocOps supports advisory and implementation readiness. It is never a substitute for an independent audit opinion, and a firm advising on readiness should not be the firm that issues the attestation.
Public review and versioning
Published openly and reviewed through a moderated public comment process. Proprietary implementation assets are not part of public review. The standard is versioned; this is v1.0. Join the review
Call to action
Read the standard. Find your stage on the adoption ladder. Produce one piece of evidence as a byproduct of work this week.
Build fast. Govern early. Stay audit-ready.