Skip to content
SALERINGOSITE v1.27.0

Review Saleringo security controls

Use the control areas to check access, data handling, audit evidence, service resilience, and the questions that must be answered for your deployment.

Follow the data, then confirm the controls.Review model, not a statement of your live deployment or an independent audit.
  1. 01
    Collection
    Purpose
    Agreed customer service
    Fields
    Minimum approved data
  2. 02
    Workspace access
    People
    Approved roles
    Providers
    Deployment-specific review
  3. 03
    Retention and exit
    Duration
    Confirm in the order
    End of service
    Agreed return or deletion
Sensitive or uncertain requests need an owner.

Confirm human review, incident contacts, countries, providers, and retention before launch.

Transparent trust review

Security Controls

Product implementation baseline · not a certification statement

These controls describe the current Saleringo product architecture. Contractual commitments, audit reports, availability terms, and deployment-specific controls must be confirmed during procurement.

Identity and least privilege

Protected operations resolve identity, active membership, workspace, tenant, region, and an exact permission rule before access.

  • High-risk actions require step-up authentication and, where configured, human approval.
  • Administrative support access is separately requested, approved, scoped, and audited.
  • Secrets and payment credentials are not accepted through public forms or URLs.

Tenant and regional data boundaries

Control-plane records and regional tenant data use explicit boundaries with tenant-scoped access policies.

  • Regional application tables enforce tenant-aware row-level security.
  • Placement projections are versioned and reconciled rather than joined across databases.
  • Data-region availability remains deployment-specific until approved for the customer.

Operational integrity

Commands are designed around atomic state changes, audit evidence, safe retries, and bounded provider calls.

  • Idempotency records protect supported commands from duplicate effects.
  • Transactional outbox and durable event handling separate state changes from delivery.
  • Provider timeouts and late-result rejection are applied at sensitive boundaries.

Start a security or procurement review

Tell us the countries, channels, data categories, and deployment scope. You do not need to design the architecture before contacting us.

Complete your security review.

Use the published controls as a review starting point. The signed order and applicable agreement remain the final authority for your deployment.

Return to the Trust Center