Security

Last updated 8 September 2026

How the system is actually built, including the parts we have not done yet. Written to be checkable rather than reassuring.

What we do not have. usellit holds no SOC 2 report and no ISO 27001 certificate. No third-party penetration test has been carried out, and we publish no uptime figure because there is not yet enough operating history to compute an honest one. All of that is on the roadmap; none of it is true today, and you should not assume otherwise because a page like this exists.

Tenant isolation

Every business is a separate tenant, and every row of business data carries its tenant. Isolation is enforced in the database by row level security, not by application code remembering to add a filter - so a missed WHERE clause returns nothing rather than returning somebody else's data.

We test this rather than assert it. An automated check creates two tenants, puts real records in both, then signs in as one and attempts to read, update, delete and take ownership of the other across every table. It also checks the opposite failure - that a tenant can still see its own data - because a database that denies everyone everything would pass an isolation test while being useless.

ERP credentials

Your NetSuite OAuth credentials are encrypted with AES-256-GCM before they are stored, using a key held only in the server environment. They live in a table with row level security enabled and no access policy at all, so they are unreachable from any browser session by construction rather than by discipline. Each environment has its own encryption key, so a compromise of one cannot decrypt another's.

Card data, and PCI scope

usellit does not store, process or transmit cardholder data, and is therefore out of PCI DSS scope. That is an architectural fact rather than a certificate: card details are captured by the payment terminal and go straight to the payment provider over their own encrypted channel. A card number never reaches a usellit server, so there is nothing for us to protect, leak or be audited on. We receive only the outcome of the payment and a masked reference - last four digits, card type, an authorization code - which is what a receipt needs and nothing more.

Be clear about what that does and does not do for you. It removes usellit from your cardholder data environment, which meaningfully narrows what you have to assess. It does not make you exempt: you still have PCI obligations for your own network, your terminals and how your staff handle cards, and your acquirer will still expect the relevant self-assessment. What we can say is that adding usellit does not widen that scope.

Environments

Production, sandbox and release preview are separate deployments with separate databases and separate keys. There is no shared table and no environment column to get wrong, so data cannot leak between them: there is no row to leak through. Non-production environments carry a permanent on-screen banner and a differently colored browser icon, so nobody does a day's work in the wrong place.

Access control

Four roles - admin, setup, view only, and point of sale - enforced in the database as well as the interface. Every action that moves money or changes configuration is attributed to a named user in an append-only audit log, which has no update or delete policy: records cannot be altered after the fact, including by the person who created them.

In transit and at rest

All traffic is HTTPS with HSTS. Databases are encrypted at rest by our infrastructure provider. Passwords are hashed by our authentication provider and are never visible to us.

The website

usellit.ai serves a strict Content-Security-Policy that permits no JavaScript at all, along with nosniff, a restrictive referrer policy and HSTS. There is no analytics, no advertising and no third-party script, so there is no third-party script to be compromised.

Reporting a vulnerability

Write to support@usellit.ai with enough detail to reproduce the issue. We will acknowledge within two working days and keep you updated. Please give us reasonable time to fix it before publishing, and do not access data that is not yours while testing. We will not pursue legal action against anyone acting in good faith under those terms.

Incidents

If a breach affects your data we will tell you without undue delay and, where we are your processor, within the timeframe the DPA requires, with what we know, what we are doing and what you may need to do.