Compliance Vocabulary

Status: Stable · v1.1 (2026-05-12). Non-normative — this document doesn't constrain any conforming openwop implementation. The few MUST / SHOULD keywords in this file are advisory to operators evaluating openwop in a regulated deployment, NOT requirements on conforming hosts; the protocol-level conformance contract lives in spec/v1/*.md + RFCS/ + the conformance suite. Maps openwop's existing protocol-level guarantees onto common compliance vocabularies (SOC 2, GDPR, HIPAA, ISO 27001) so operators have a shared reference. See auth.md for the status legend.

Why this exists

Operators in regulated industries (financial services, healthcare, public sector, EU-resident services) evaluate every infrastructure choice through compliance lenses. "Does openwop support audit-log retention?" is the wrong question — openwop is a protocol, not a deployed service. The right question: "What guarantees does the protocol surface, and which compliance controls do those guarantees satisfy when an operator runs a host that passes the openwop conformance suite inside their certified perimeter?"

This document maps protocol-level surfaces onto common control vocabularies. It does NOT prescribe certification (certification is the deployer's responsibility) and does NOT make legal claims about regulatory adequacy (compliance is a context-specific judgment that requires a qualified auditor + counsel). It does describe what the protocol gives an operator to work with.

Scope and non-claims

In scope:

• Mapping protocol-level guarantees (in auth.md, auth-profiles.md, replay.md, webhooks.md, observability.md, production-profile.md, SECURITY/) onto control families in SOC 2 Trust Services Criteria, GDPR articles, HIPAA Security Rule safeguards, and ISO 27001:2022 Annex A.
• Identifying which protocol surfaces an auditor would inspect to verify a given control.

Out of scope:

• Deployment-specific posture (key management, employee access, physical security, data-residency arrangements). These are the operator's responsibility.
• Certification or attestation. The protocol can be used inside a certified environment; the protocol itself is not certified.
• Legal advice. This document is technical reference, not regulatory guidance.

Non-claims:

• openwop does NOT claim to be "SOC 2 compliant," "HIPAA compliant," or "GDPR compliant." A protocol cannot hold those certifications. Deployments hold them; the protocol is one input.
• Operators MUST consult qualified legal and compliance professionals before claiming any regulatory status based on protocol surfaces.

Trust Services Criteria (SOC 2)

GDPR (EU 2016/679)

HIPAA Security Rule (45 CFR Part 164)

Note on PHI (Protected Health Information): The protocol does not define a "PHI" data class. Operators that route PHI through openwop SHOULD use the [REDACTED:<id>] pattern in agent-memory.md §SR-1 to keep PHI out of observable channels, plus deployment-specific encryption-at-rest controls.

ISO/IEC 27001:2022 Annex A

Compliance-relevant protocol primitives

The following surfaces are most often cited in compliance reviews. They are normative parts of the openwop spec; this doc is the cross-reference.

• Authentication / authorization. auth.md, auth-profiles.md.
• Audit log + integrity verification. auth-profiles.md §openwop-audit-log-integrity, /v1/audit/verify.
• Secret redaction. SECURITY/threat-model-secret-leakage.md §SR-1, agent-memory.md, observability.md §Redaction.
• Tenant isolation. auth.md §Tenant isolation, agent-memory.md §CTI-1.
• Retention + expiry. production-profile.md §Event retention, replay.md §Retention and garbage collection.
• Encryption-in-transit. auth-profiles.md §openwop-auth-mtls for client→host; webhooks use TLS to subscriber endpoints per webhooks.md.
• Encryption-at-rest. Out of protocol scope — deployment concern. Operators wire to KMS / database TDE / object-store SSE.
• Observability + traceability. observability.md (W3C Trace Context + openwop.* OTel namespace).
• Provenance. auth-profiles.md §openwop-audit-log-integrity audit log records actor + action + target.

How to use this document

1. Pick a compliance framework (SOC 2, GDPR, HIPAA, ISO 27001) that applies to your deployment. 2. Identify the controls your auditor cares about — your compliance team can produce this list. 3. Cross-reference here to find which protocol surface each control inspects. 4. Verify the host you're using actually implements that surface by consulting INTEROP-MATRIX.md — claim ≠ conformance evidence; the matrix records what each host has actually demonstrated. 5. Layer the deployment-specific controls (key management, employee access, data residency) that the protocol cannot provide.

If a compliance control you need isn't reflected here, file an issue. The intent is that this document grows with every new compliance framework that openwop deployments encounter.

See also

• auth.md — bearer-token authentication and scope vocabulary
• auth-profiles.md — optional production-auth profiles (rotation, OAuth2-CC, OIDC, mTLS, audit-log integrity)
• agent-memory.md — memory layer + SR-1 secret redaction + CTI-1 cross-tenant isolation
• production-profile.md — public-release operational profile (durability, backpressure, retention)
• replay.md §Retention and garbage collection — replay history retention semantics
• observability.md — openwop.* OTel namespace, W3C Trace Context propagation
• SECURITY.md — coordinated disclosure process
• SECURITY/threat-model-*.md — five published threat models (auth, packs, prompt-injection, provider-policy, secret-leakage)
• INTEROP-MATRIX.md — per-host conformance evidence