Security
Setliva handles debt and dispute records, which are among the more sensitive things a business holds about its customers. This page sets out what we do, and is explicit about what we have not yet certified.
Last updated 1 September 2026
Certification status
We are not currently certified to SOC 2, ISO 27001 or PCI DSS, and we will not imply otherwise in a sales process. Independent assessment is on the roadmap; until it is complete, what follows is a description of our practices rather than an audited assertion.
The product is not a payment processor and does not store primary account numbers. Card data reaches the product only as the truncated identifiers, response codes and reference numbers that appear on dispute records — an authorisation code, an AVS or CVV2 result, an acquirer reference number.
Protecting data
- Data is encrypted in transit with TLS 1.2 or higher, and at rest by the storage layer.
- Access to production data is role-based, least-privilege, and granted only for a named operational reason.
- Administrative access requires multi-factor authentication.
- Customer data is logically segregated, and a case can only be read in the context of the account that owns it.
- Secrets are held in managed secret storage and never in source control.
Auditability
Two properties of the engine are security controls in their own right, and both are verifiable rather than asserted.
- Every consequential action writes an entry to a hash-chained audit trail. Each entry commits to its predecessor, so altering, deleting or reordering an entry breaks verification of everything after it. The chain is recomputed on every read.
- Decisions are deterministic. The same case under the same policy always produces the same result and the same digest, so a decision taken months ago can be reproduced exactly rather than reconstructed from memory.
Together these mean that if someone asks why an account was pursued, or why a representment was filed, the answer is retrievable and provably unmodified.
How we build
- Changes go through review before merge, and the build blocks on type checking and linting.
- Dependencies are pinned and monitored for known vulnerabilities.
- The decisioning logic is covered by a fixed regression corpus that exercises every gate, including the cases that must never result in pursuit.
- Infrastructure is defined in code and deployed through an automated pipeline; there is no manual production configuration.
Availability and continuity
The service runs on managed, multi-region infrastructure with automated failover. Data is backed up daily with point-in-time recovery, and restores are tested.
Deadlines are the operational risk that matters most here: a representment window that closes is money lost outright. Cases inside their filing buffer are surfaced at the top of the queue and routed to a person rather than left in an automated flow.
Incident response
We maintain an incident response process covering detection, containment, eradication, recovery and review.
Where a personal data breach affects a customer’s data, we will notify that customer without undue delay and in any event within 72 hours of becoming aware, with the information they need to meet their own notification obligations.
Reporting a vulnerability
If you believe you have found a security issue, write to hello@setliva.com with enough detail to reproduce it. Please give us a reasonable period to investigate and remediate before disclosing publicly.
We will acknowledge within two working days, keep you updated, and credit you if you would like to be credited. We will not pursue legal action against anyone acting in good faith under this policy, provided you do not access data belonging to others, degrade the service, or exfiltrate data.
We do not currently run a paid bug bounty.