Customer Privacy Policy

Status: skeleton — pending counsel review. This document describes what the OrbitalReg Software does with Customer data when Customer self-hosts. It is the post-sales counterpart to the marketing-site privacy policy (which covers website visitors and pre-sales contacts) and is distinct from the EULA and Terms of Service.

Scope

This policy applies to the OrbitalReg software that you, the Customer, run on your own infrastructure. It explains:

• What data the Software processes locally
• What outbound network calls the Software makes (and how each can be turned off)
• What data, if any, leaves your infrastructure under each configuration

Key principle. Your customer data stays with you. When you self-host OrbitalReg, the artifacts, audit logs, scan findings, and user metadata never leave your installation unless you explicitly opt in to a feature that requires outbound data flow. The default install in air-gapped mode (see Air-gapped mode) blocks every outbound call until an admin whitelists each integration.

[ANWALT-REVIEW] — counsel to confirm DSGVO Art. 28 boundaries: because the Software runs on Customer infrastructure, OrbitalReg / OrbitalReg GmbH is not a Auftragsverarbeiter for the Customer's end-user data; the Customer is the Verantwortlicher. The Customer's own DSGVO obligations are out of scope of this document.

A narrow processor relationship does exist for the Customer Portal at portal.orbitalreg.com — when a Customer-employee Authorised User signs in to retrieve a License Key or download a release. That relationship is governed by the Data Processing Agreement. It is separate from the self-hosted Software flow this Customer Privacy Policy covers.

What the Software processes locally

The following data classes are processed entirely within your installation. They never leave the boundary unless an outbound feature listed below is explicitly enabled:

Data class	Where it lives	Retention
Artifact binaries	Customer-provided S3 / object store	Customer-controlled
Artifact metadata	Postgres	Customer-controlled
User accounts (local + SAML)	Postgres	Customer-controlled
API tokens (hashed)	Postgres	Token TTL (default 365 days)
Audit log	Postgres + structured JSON logs	Customer-controlled (default ∞)
Scan findings	Postgres	Customer-controlled
SBOMs	S3 (/sboms/) + Postgres references	Customer-controlled
License Key metadata	Postgres single-row + /etc file	Subscription term

Customer is the data controller (Verantwortlicher) for all of the above under DSGVO / GDPR Art. 4 (7) and equivalent regimes.

What the Software optionally sends outbound

Each of the following is opt-in in air-gapped mode and can be toggled per environment via the listed configuration variable. The Air-gapped mode page is the canonical reference for the egress matrix.

Update check (Item 69)

• What. A periodic GET against the configured release-channel manifest URL to learn whether a newer CalVer release is available.
• Data sent. Standard HTTPS request headers. The current installed version is not transmitted — the comparison is performed locally after the manifest is fetched.
• Default state. Off in every fresh installation. The update_check_settings.manifest_url ships empty, so the background worker short-circuits before it can reach the network. Operators opt in actively — either by picking Daily or Weekly in the Update check step of the First-Run Setup Wizard (Item 76) or, for an existing install, by setting the manifest URL via Admin → Version status → Settings (/admin/version-status/settings).
• How to disable (after opt-in). Clear the manifest URL on the same admin page, or pick Off in the wizard. The air-gapped egress gate also suppresses the request regardless of the per-row setting, so a regulated install can leave the gate denied as a belt-and-braces second layer.
• Endpoint. https://updates.orbitalreg.com/manifest.json (or a Customer-pinned mirror) — only contacted after the operator has explicitly populated the manifest URL.

CVE / vulnerability feeds

• What. Periodic pulls from OSV / NVD / GHSA / scanner-vendor feeds to keep the on-box vulnerability database current.
• Data sent. None outbound — the Software only reads remote feeds, it does not send Customer data.
• How to disable. Air-gapped installs disable all CVE-feed pulls by default. An admin can pre-stage a curated CVE bundle on disk for offline ingestion (see Air-gapped mode §"CVE feed ingestion").

Sigstore Rekor lookups

• What. When verifying a Sigstore-signed artifact, the Software may consult the public-good Rekor transparency log to confirm a signature was logged.
• Data sent. Artifact digest (SHA-256). The digest itself is not personally identifying; in some narrow threat models it can reveal that someone is verifying that artifact.
• How to disable. Configure the Sigstore trust policy to use offline verification mode (signature + identity check only, no Rekor consultation). Rekor lookups are off by default in air-gapped mode.

Webhook deliveries

• What. When Customer configures a webhook subscription (Item 5 / Item 7), OrbitalReg POSTs event payloads to the Customer-configured URL.
• Data sent. Determined by Customer's subscription. The payload schema is documented per event in Reference / API.
• How to disable. Delete the webhook subscription. Air-gapped installs reject webhook URL configuration that does not match the air-gapped allow-list.

OpenTelemetry traces (Item 22)

• What. When Customer configures an OTLP exporter, OrbitalReg emits trace spans to the Customer-configured endpoint.
• Data sent. Spans contain operation names, durations, status codes, and a small bounded set of attributes (request_id, trace_id, principal_id — the last is a UUID, not an email). PII redaction (Item 71 Phase F) can scrub additional attributes before export.
• How to disable. Unset OTEL_EXPORTER_OTLP_ENDPOINT. Off by default in air-gapped mode.

License-server check-ins (Item 67)

• What. Optional online License Key validation — not active in v1. Today's License Key verification is fully offline (Ed25519 signature check on the local envelope). Future revisions may add an opt-in online check-in for shared-floating-instance entitlements.
• Data sent. License Key fingerprint, instance UUID, current feature usage counts. No artifact contents, no user data.
• How to disable. N/A in v1 (offline-only). When the online check-in is added, it will be opt-in and disabled in air-gapped mode by default.

Sentry / error reporting

• Status. Not enabled. OrbitalReg does not ship a Sentry / Bugsnag / Rollbar integration in v1. Frontend client- side errors are forwarded to the Customer's own OrbitalReg installation only (Item 71 Phase E), never to a SaaS provider.

What the Software never sends outbound

The following data classes are processed locally only. There is no configuration that causes them to leave the Customer installation:

• Artifact binaries (the actual package contents)
• Artifact metadata (paths, versions, checksums)
• Authenticated user emails or names
• Local-account password hashes
• SCIM-provisioned identity attributes
• Audit-log content
• Scan findings (other than the public CVE identifiers used to query feeds — and only the CVE identifier travels outbound, not the affected-artifact mapping)

[ANWALT-REVIEW] — counsel to confirm this list is exhaustive and to add explicit DSGVO Art. 32 (security) language about the encryption-at-rest defaults.

DSGVO / GDPR alignment

[ANWALT-REVIEW] — counsel to draft the formal Art. 28 framing. Tentative outline:

• Customer is data controller for all end-user data (artifact-uploaders, package consumers, admin users) under Art. 4 (7).
• OrbitalReg / OrbitalReg GmbH is not a processor in the technical sense — the Software runs on Customer infrastructure and does not provide a hosted data-processing service. OrbitalReg acts as a software vendor, not a processor.
• A Data Processing Agreement (DPA / Auftragsverarbeitungsvertrag) is therefore not the standard contract shape; the EULA suffices. Where Customer's DSGVO programme requires an Art. 28 DPA, a template is available on request.
• Sub-processor disclosures: as a software vendor, OrbitalReg does not engage sub-processors that process Customer's end-user data. Customer's choices of S3 provider, identity provider, and scanner backends are the relevant sub-processor relationships on Customer's side.

Telemetry by tier

• Free Forever. No outbound telemetry. The update check is off by default in every fresh installation; the operator opts in via the First-Run Setup Wizard or by populating the manifest URL on Admin → Version status → Settings.
• Commercial / Enterprise. Same baseline; License Key verification is fully offline. Online check-in (if added in a later revision) is opt-in.

The default-deny-egress posture is part of the brand promise and will not be silently changed by a software update. A future change to the egress matrix would be a documented breaking change under the Versioning policy.

Contact

• Privacy questions: privacy@orbitalreg.com
• Security incidents: security@orbitalreg.com (see Vulnerability disclosure)
• Legal contact: legal@orbitalreg.com

Document control

• Draft version: v0 (skeleton, pending counsel review).
• Last edited: see this page's "last updated" footer.
• Counsel review status: not yet reviewed. All [ANWALT-REVIEW] markers must be cleared before this document is binding.

See the EULA and Terms of Service for the companion documents.