Skip to main content
Privacy in practice

Data handling

What we keep, the form it takes, and how long it remains.

Read the Privacy Policy

Two kinds of data, different purposes

This inventory explains current application behavior. It does not replace the Privacy Policy or change your rights. Expiry can stop a credential from working before its record is deleted. Historical data and operator-managed cleanup are called out below.

Carrier lookups can send a phone number transiently to Twilio, Vonage or Sinch, depending on the configured provider. That processing is described in Privacy Policy sections 5 and 10.

Account and service data

Running an account requires contact, administration and service records. These have their own purposes and retention; the signal-processing privacy promise does not make account content anonymous.

Account and sign-in records

What we keep
Account contact details, display names, linked sign-in providers, authentication factors and session records. These are account data, separate from the identifiers in identity signals.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Public keys, signatures and non-secret cryptographic records
  • Digests of random credentials; the original credential is not recoverable
Retention
Kept while the account is needed. Closing an organization schedules removal within 30 days; a sign-in account shared with another organization remains while that membership is needed.

Organization settings

What we keep
Organization names, memberships, roles, plan settings, configured destinations and response policies. Labels and free-form configuration can contain what an administrator enters; do not put end-user identifiers in them.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Kept with the organization and removed through account closure. Some audit evidence of configuration changes is retained separately.

Integration credentials

What we keep
Registered provider connections, signing keys and secrets needed to operate an integration. Random API credentials are represented by digests; credentials needed again are encrypted or held in restricted service configuration.
Storage form
  • Encrypted values that an authorized operation can read again
  • Digests of random credentials; the original credential is not recoverable
  • Public keys, signatures and non-secret cryptographic records
  • Structured metadata, counts and operational records
Retention
Until revoked, replaced or removed with the account. Revocation can stop use while retaining the record as evidence; expiry does not by itself mean every historical row is deleted.

Provisioning records

What we keep
Organization membership identifiers, provisioning operations and identity-provider account labels. New labels are encrypted separately for each membership. Provisioning logs retain account-management metadata.
Storage form
  • Encrypted values that an authorized operation can read again
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Encrypted labels remain with the membership, including while it is inactive, and are removed when that membership is deleted. Other provisioning history follows account retention.

Billing and usage records

What we keep
Subscription references, metered signal counts, reporting state and short-lived coordination records. Payment-card details are processed by the payment provider rather than stored as signal data.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Usage totals are retained for 12 months under the Privacy Policy. Other billing state stays with the account; temporary coordination and deduplication records have their own shorter cleanup windows.

Support and notifications

What we keep
Support tickets, administrative notes, status changes and in-product notifications. Submitted text is kept as account content; automated identifier filters cannot guarantee that arbitrary prose contains no personal data.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Kept for the account and support purpose, subject to erasure requests and account closure. Removing a linked signal event does not remove the text of its support ticket.

Uploaded documents

What we keep
Documents operators choose to retain and the metadata controlling access to them. File contents remain as uploaded; this inventory does not describe them as identifier-free.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Until removed under the applicable document process. No single automatic file-expiration period is asserted here.

Newsletter records

What we keep
Opted-in delivery addresses, subscription state and delivery metadata. Delivery addresses are encrypted, with keyed digests used for matching.
Storage form
  • Encrypted values that an authorized operation can read again
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Delivery stops when you unsubscribe. Subscription and suppression records may remain to honor that choice; you can request erasure under the Privacy Policy.

Business prospecting records

What we keep
Professional contact details, their source, outreach delivery and engagement records, and suppression choices. This is business contact data, outside identity-signal processing.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Until objection or 24 months after the last outreach email, or import if no email was sent. An objection leaves the address needed to prevent further outreach; the other prospect fields are cleared.

Evidence requests

What we keep
A requester’s name and work address, company and request details, consent acknowledgments, review notes and notification state. Contact name and address are encrypted.
Storage form
  • Encrypted values that an authorized operation can read again
  • Plaintext account and administrative data, protected by access controls
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Used for the evidence-request and associated agreement process, subject to account-data retention and applicable erasure rights. No separate automatic expiry is claimed for every request record.

Account recovery

What we keep
Guardian relationships, keyed contact references, approvals, request status, expiry and security-notice delivery records. Recovery security links can be held as encrypted values and random-token digests; recipient addresses are read from account records when sending. A recovery concerns a platform account rather than an end-user signal identifier.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Encrypted values that an authorized operation can read again
  • Digests of random credentials; the original credential is not recoverable
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Requests stop being usable at their expiry or terminal state. Relationship and request history remain account records until removed under the recovery or account-closure process.

AI connector approvals

What we keep
The approving administrator’s account reference, the chosen client, allowed access, return host and approval dates. The client receives the limited security data its administrator approved.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Approvals last at most 90 days; revoked or expired approvals remain as account history. Authorization codes last 2 minutes, access tokens 30 minutes, and refresh tokens up to 30 days; expired tokens are removed within an hour.
Privacy Policy
Section 7Section 11

Audit and integrity evidence

What we keep
Actor and resource references, action, time, result, minimized change metadata and integrity proofs. Application audit network identifiers use keyed digests. Account-authentication records are described separately above.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
  • Public keys, signatures and non-secret cryptographic records
Retention
Audit history is retained as evidence; application audit IP and user-agent digests are cleared after 90 days. Integrity evidence can remain after the underlying event or organization is removed.

Security configuration and reviews

What we keep
Configured alert rules, posture-check results, investigation notes, emergency-access approvals and administrative security review records. Free-form notes remain account content.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Kept for the organization and investigation purpose. Emergency-access history remains for the life of the organization; other records are subject to account closure and erasure rights.

Website measurement and diagnostics

What we keep
Page paths, fixed funnel dimensions, aggregate engagement and bounded error diagnostics. Contact values are excluded from the analytics dimensions; free text is filtered rather than treated as a proof of anonymity.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Retention depends on the measurement or diagnostic record. This page does not promise a single expiry for every analytics or error record; applicable rights are in the Privacy Policy.

Service operations

What we keep
Service-health checks, scheduled-task state, engineering review records, deployment history, operational responses and reference data used for verification. These are service records, separate from customer signal bodies.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
  • Public keys, signatures and non-secret cryptographic records
Retention
Health snapshots are retained for 13 months. Other operational and engineering records use their maintenance or evidence lifecycle; no universal expiry is asserted.

Legacy copies and migration history

What we keep
Restricted rollback copies, migration counts and legacy account labels awaiting the manual auth-record backfill. Older records can retain earlier identifier representations; current keyed writes do not retroactively change every historical copy.
Storage form
  • Plaintext account and administrative data, protected by access controls
  • Legacy unkeyed digests retained pending migration or guarded rollback retention
  • Encrypted values that an authorized operation can read again
  • Structured metadata, counts and operational records
Retention
Rollback copies are kept until their recorded retention or review dates. Legacy plaintext account labels remain until the guarded operator backfill succeeds; retained encrypted counterparts are not represented as deleted.

Privacy requests

What we keep
Access, export and erasure requests, keyed subject references, processing status and response records.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Plaintext account and administrative data, protected by access controls
  • Structured metadata, counts and operational records
Retention
Retained for handling the request and demonstrating its response. No separate automatic expiry is asserted for every request record; applicable rights are described in the Privacy Policy.

Identity signal data

Personal identifiers in signal processing are keyed before storage. Values needed again are encrypted. Public keys, decisions and contextual metadata have different storage and retention needs.

Signal events and decisions

What we keep
Signal types, keyed subject digests, risk and timing values, correlation references, action results and selected decision metadata. An opaque correlation handle is retained as supplied and must not contain a personal identifier.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Signal events are purged after 90 days. Related intelligence follows the event; audit evidence and delivery history have separate retention described on this page.

Device and provenance observations

What we keep
Keyed device, user and sensor digests; verification outcomes; capture timing and contextual observations such as location or proximity when a verification feature uses them. Raw sensor traces are reduced on the device rather than stored as traces.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
  • Public keys, signatures and non-secret cryptographic records
Retention
Validity and retention depend on the enrollment or verification record. Expired or revoked state does not imply immediate physical deletion; erasure and account closure provide separate removal paths.

Hosted passkey credentials

What we keep
Credential identifiers, public keys, counters, transports, authenticator and backup metadata, plus a keyed digest of the organization’s user handle. Biometric samples and authenticator private keys stay on the user’s device.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Public keys, signatures and non-secret cryptographic records
  • Structured metadata, counts and operational records
Retention
Credentials remain until deleted through the credential or user API, or removed with account closure. Ceremony challenges are single-use and expire after five minutes.

Credential and trust artifacts

What we keep
Keyed subject references, public proofs, credential status, agent activity and trust state, re-attestation schedules, and encrypted values needed for pending issuance, cached proofs, proxy values or protected sessions. Issued credential claim values are not stored as a full issued credential.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Encrypted values that an authorized operation can read again
  • Public keys, signatures and non-secret cryptographic records
  • Structured metadata, counts and operational records
Retention
Use is bounded by the artifact’s expiry and revocation state. Physical retention varies by artifact and removal path; encrypted pending values and historical proof metadata do not all share the event-log expiry.

Signal exchange and delivery

What we keep
Normalized carrier results, security-event subjects, delivery metadata and retry payloads. Identifiers are keyed; raw inbound security tokens and protected retry material are encrypted. Known identifier fields are removed from outbound metadata.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Encrypted values that an authorized operation can read again
  • Structured metadata, counts and operational records
Retention
Delivery history can remain after its linked signal event is purged; it has no independent 90-day automatic purge in the application. Applicable erasure and account-closure paths remain available.

Shared threat indicators

What we keep
An opt-in keyed digest of a submitted indicator, its classification, severity and contributor counts. The submitted digest is keyed again before storage; a raw personal identifier is refused.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Structured metadata, counts and operational records
Retention
Contribution records are removed with their organization. Shared indicator lifecycle follows its aggregation and sharing policy rather than a promise that every row expires with an individual event.

Decision measurement

What we keep
Signal classification, decision confidence, escalation counts, timing and correlation references. Response history records scope, ordered actions and outcomes, with a keyed subject reference and an encrypted selector for safe retries. These records are separate from the signal event itself.
Storage form
  • Keyed HMAC-SHA-256 under a server-held pepper
  • Encrypted values that an authorized operation can read again
  • Structured metadata, counts and operational records
Retention
Kept for decision review and removed through the applicable account lifecycle. These records have no independent 90-day automatic purge; deleting a signal event does not establish that its separate measurement was deleted.

For access, correction, export or erasure, follow Privacy Policy section 12.