Trust and security

Your data is yours. Here is exactly how we prove it.

StoreRounds reads a fixed set of your sales numbers, read-only, and sends the day's totals out over an encrypted connection. A second, separate door, the phone capture feature, handles photographed slips that carry bank and personal details, so we disclose it here in full, at the same volume, and hold it to stricter rules. Every claim on this page is one you can check yourself.

Last updated 2026-07-10 · storerounds.com/security

Where the product stands, said plainly

StoreRounds today is a working product prototype. Production connectors are being proven with the founding cohort, and this page states the security posture those connectors are built and audited to. The formal privacy and data-processing paper behind these commitments is with counsel now; until that review completes, this page is the binding public statement of our practice, and if anything changes, this page changes first.

한국어 요약

커넥터는 지정된 테이블만 읽기 전용으로 읽고, 나가는 방향으로만(TLS, 포트 443) 통신하며, 들어오는 포트는 하나도 열지 않습니다. 사장님이 직접 권한을 감사하고 몇 초 안에 회수하실 수 있습니다. 데이터는 팔지 않고, 동의 없이 다른 고객과 공유되는 모델을 학습시키지 않습니다. 전표 사진(캡처) 경로는 은행 정보와 개인 정보를 다루므로 더 엄격한 규칙이 적용되고, 은행 정산 확인이 생기기 전에는 사진만으로 VERIFIED 도장이 찍히지 않습니다. 아직 안 된 것(SOC 2, 침투 테스트, 서명된 DPA 등)은 아래 로드맵에 그대로 적어 두었습니다.

이 한국어 요약은 이해를 돕기 위한 안내이며, 기준이 되는 전체 내용은 위 영문 페이지입니다. 정식 개인정보 · 데이터 처리 문서는 현재 변호사 검토 중입니다. 한국어로 궁금하신 점은 [email protected]으로 편하게 문의해 주세요.

Three promises

Yours to keep, export, and delete. Export or delete your data from Settings, then Data, on your own schedule, without asking us. When you delete, it is removed from our side too, on a stated timeline, not held quietly in a backup forever.
Never sold. Not to anyone, not at any price. No data brokers, no advertisers, no competitors. Our business is the subscription. The signed Data Processing Addendum that writes this into your contract is with counsel; until it is countersigned, this stands as our binding practice and public promise.
Never trains a shared model without your consent. Your chain's data trains your chain's memory, walled to your account. The cross-chain StoreRounds Index runs only on explicit, written, revocable owner consent, off by default. Withdrawing consent stops all future inclusion, though it cannot un-compute a benchmark already published.

What the connector reads, and what never leaves your store

The connector pulls a narrow, named set of sales and store tables and aggregates the day's totals on your machine before anything is sent. Totals travel, not a row-by-row copy of your database.

What the connector reads

Daily sales header: date, store, totals, transaction count.
Sales lines, for category and product-level totals.
Tender split: cash versus card totals, for reconciliation.
Store codes and names, to label each location.

What the connector never reads

Payment card numbers, PAN, or track data. Never read, at all.
Any table the read-only user was not explicitly granted.
Employee records and customer personal data.
A full export of your database. Only aggregated totals go out.

The connector security model

The connector is a small, signed program on your back-office computer. Once a night it signs in to your POS database as a read-only user, copies the day's numbers for the stores you named, and sends them out over one encrypted connection. That is the whole job. It is not a remote-access tool, and no one at StoreRounds gets a session on your machine.

It can

Run SELECT queries against the named table groups only.
Open one outbound TLS connection to a single StoreRounds host on 443.
Aggregate the day's totals locally and send those totals out.
Report its own health and log every poll and send as receipts.

It cannot

Insert, update, delete, or alter any row or object. Writes are denied at the database.
Accept any inbound connection. It opens and listens on no port.
Give anyone at StoreRounds a shell, RDP, or interactive session.
Move laterally. One read-only credential, one database, no domain rights.

A printable one-page version of this model, with the exact grants and audit queries for your IT person, ships with onboarding.

The capture path, and the bank and personal data it handles

The connector is not the only door. The capture feature lets a staff member photograph a deposit slip, a check deposit, or an invoice so the day's paper reconciles against the day's numbers. Said straight: a deposit or check slip carries a bank account number and a routing number, and an invoice can carry a name. This path handles personal and bank information, the exact class of data the connector deliberately never touches, and it is held to stricter rules.

Every upload is validated at the server: real image type checked by content, size limited, image re-encoded, EXIF and location data stripped, SVG refused.
Stored encrypted at rest under keys scoped to your chain, with retention limited to the reconciliation window, not kept forever.
Attribution is by login, never by face or fingerprint. No biometric is read from a photo.
An OCR amount is a draft a person confirms, never a number acted on unseen, and text inside a photo is data to reconcile, never a command the software obeys.
A mismatch names data to look into, never a person at fault.

Why VERIFIED waits for the bank: matching a slip photo to the point-of-sale is a real check, but it is not the same as confirming the deposit cleared the bank. Until the bank-settlement feed on the roadmap exists, a slip-only reconciliation is marked provisional, and StoreRounds does not stamp a deposit VERIFIED on the strength of a photograph alone.

Least privilege, all the way to the person

The owner sees every store and the money, and is the only role that can grant money-visibility to anyone else.
A regional or HQ manager sees a defined set of stores, with no financials unless the owner explicitly turns them on.
A store manager sees their store only, completes assigned rounds, and submits receipts.
Staff and cashiers get no dashboard and no standing access: a task reaches them as a single scoped link.

Every grant, revocation, and sensitive view lands in an audit trail. A task closes with proof the work is done and the number is right, not a log of who was watched. Receipts, never surveillance.

Don't take our word for it. Audit it, and revoke it.

Audit: list every permission the storerounds_ro login holds and expect only SELECT on the named tables. Watch the connector's single outbound destination at your firewall. Review its sessions in your normal database views. Read its local event log, mirrored in the owner's dashboard.

Revoke, immediately, as your own action: drop the read-only user, or remove the connector. Either one is enough on its own.

-- SQL Server
USE [<YOUR_POS_DB>]; DROP USER [storerounds_ro];
USE [master];        DROP LOGIN [storerounds_ro];

-- MySQL / MariaDB
DROP USER 'storerounds_ro'@'10.0.0.%'; FLUSH PRIVILEGES;

Your POS database is unchanged by any of this, because the connector never had, and never used, write access.

Subprocessors

We use a small number of vendors to run the service: cloud hosting and storage, error and uptime monitoring, transactional email, and payment processing. The full named list, with what each vendor does, what data it can touch, and where it runs, is published before any customer connects a store, and we give notice before adding a subprocessor that can touch customer data. We would rather show you the frame now than name a vendor we have not finalized.

What exists now, and what is on the roadmap

We would rather tell you what we have not built than let you assume we have. The same rule the product runs on: say what is not ready at the same volume as what is.

In place today

TLS 1.2 or higher in transit, encryption at rest.
Read-only, least-privilege database access to named tables.
Outbound-only connection, no inbound ports opened.
Credential held in the machine's protected credential store.
Signed connector installer.
Audit trail on access, plus a local connector event log.
Self-serve revoke, data export, and data delete.
Per-user least-privilege roles, money-visibility gated to the owner.

On the roadmap

Server-enforced access boundary, built before the first live chain connects.
Bank-settlement confirmation for deposit reconciliation.
SOC 2 Type II. We are not SOC 2 certified today, and we will publish the report date when we hold it, not one day before.
Independent third-party penetration test, summary published.
Signed Data Processing Addendum, and email notice of subprocessor changes.
Single sign-on (SAML / SSO) for larger chains.
Customer-managed encryption keys.
A published coordinated-disclosure policy.

A roadmap item is a roadmap item until it is real and checkable, at which point it moves to the left column with a date. If a page ever claims otherwise, it is wrong, and this line is the one to trust.

Found something? Tell us.

If you or your technician find a security problem, report it to [email protected]. If that address ever fails, [email protected] reaches the founder. We read these, we respond, and we do not pursue good-faith research that follows responsible disclosure.