Security · revised 2026-07-14 · the DPA and its Annexes control

RevenueOS — Security Overview (pilot one-pager)

Informational summary, as of 2026-07-08. The Data Processing Addendum ("DPA") and its Annexes — published at https://www.revenueos.app/dpa — are the controlling documents: where this overview and the DPA differ, the DPA controls. This overview is provided for convenience during pilot evaluation; it is not a warranty, not a certification, and not an amendment of any agreement.

What RevenueOS is

RevenueOS is a revenue-orchestration platform. For pilot customers it processes prospect business-contact data and outreach/outcome event data on the customer's behalf, as processor, under the DPA. The categories of data, the processing purposes, and the retention rules are defined in the DPA and the Privacy Policy (https://www.revenueos.app/privacy) — this overview does not restate them.

Certifications — none claimed

RevenueOS does not currently hold SOC 2, ISO 27001, or comparable third-party certifications. The DPA's Annex II states our measures "as actually implemented, without certification claims": we describe what actually runs, calibrated to our current scale of operations, and we do not borrow assurance language we have not earned.

Technical and organizational measures — DPA Annex II, verbatim

The complete measures list from DPA Annex II is reproduced below byte-for-byte. An automated drift test fails our build if this block and the DPA source of truth ever diverge — it verifies both that every measure matches the DPA exactly and that the block contains nothing but the DPA's own list — so this block cannot silently overstate or understate the DPA's measures. (Prose outside the block is this document's own summary; where it and the DPA differ, the DPA controls.) Section and Annex references inside the quoted text refer to sections of the DPA.

  • Encryption in transit: TLS for data in transit between clients, the application, and the datastore.
  • Encryption at rest: platform-provided encryption at rest on the managed database platform hosting the primary datastore.
  • Tenant isolation: application-layer tenant isolation applied on every data-access path, with database row-level-security policies defined at the database layer as an additional backstop.
  • Access control: authentication through a managed identity provider; role- and attribute-gated authorization for administrative and privileged operations; least-privilege service credentials.
  • Audit logging: durable audit logging of privileged operations — including data-subject-request execution and erasures — written before the privileged operation proceeds. Audit records are additionally sealable through an out-of-band tamper-evidence mechanism whose KMS-backed signing operates over cryptographic hash values only; no Personal Data content is sent to the key-management service.
  • Telemetry hygiene: redaction of personal data from application telemetry and operational logs.
  • Legal-evidence ledgers: append-only, immutable records of Terms acceptance and Pooled Intelligence consent decisions, with immutability enforced at the database.
  • Data-subject-request tooling: tenant-scoped DSR intake with deadline tracking, subject-scoped export, and subject-scoped erasure with audit-before-erasure, as described in Section 8.
  • Deletion: a tenant deletion cascade with the documented retention carve-outs in Section 9; re-application of previously executed erasures following any restoration from backup.
  • Secrets management: credentials and keys held in platform secret stores; no secrets in source control.
  • Pooled-statistics protections (where elected): a minimum cohort of five distinct participating customers (k-anonymity floor) and centrally applied differential-privacy noise (Laplace mechanism) on Aggregated Statistics releases, as described in Annex IV.
  • Personnel and subcontractors: confidentiality obligations under Section 4 and Subprocessor flow-down under Section 6.
  • Onward-transfer measures. For onward transfers to Subprocessors, the measures each Subprocessor applies are described in that Subprocessor's own security documentation, referenced through the resources listed in Annex III.

A note on "append-only". The database-enforced immutability described above applies to the two legal-evidence ledgers it names (Terms acceptance and Pooled Intelligence consent decisions). Other audit records are durable and written append-only as a matter of application design; we do not claim database-enforced immutability for them. Telemetry is redacted of personal data as described above, but it is operational log data — rotated, not retained as an immutable record.

Breach notification

Our breach-notification commitments — the notice trigger and timing, the content and phased updates, and the parties' roles — are stated in Section 10 of the DPA. That section controls, and this overview deliberately does not restate its timelines: a summary that drifted from the DPA would be worse than no summary.

Subprocessors

The current subprocessor list — each vendor's function, the personal data it touches, its region, and the transfer mechanism relied on — is Annex III of the DPA at https://www.revenueos.app/dpa. Changes follow the DPA Section 6 notice-and-objection process. This one-pager does not carry its own copy of the list, so it cannot go stale against the canonical one.

Data subject requests and deletion

Tenant-scoped DSR intake, subject-scoped export, subject-scoped erasure (with audit-before-erasure), the tenant deletion cascade, and the re-application of previously executed erasures after any restoration from backup are described in DPA Sections 8–9 and mirrored in the Annex II list above. The individual-facing process is described in the Privacy Policy.

Security contact

Security questions, questionnaires (per DPA Section 13.1), and vulnerability reports: legal@revenueos.app.

How this document stays honest

This one-pager is drift-locked to the legal corpus by an automated test (`backend/src/services/legal/__tests__/pilotKit.drift.test.ts`): the Annex II block above must remain byte-identical to the DPA source of truth and may contain nothing else, this document must never state a breach timeline outside the DPA, and it must never restate the subprocessor vendor list. When the DPA bumps versions, this document is re-mirrored in the same change.

As of 2026-07-08 · draft, pending counsel review · The DPA and its Annexes control. This overview is informational only and is not a warranty.