Security

How your data is protected

Encrypted in transit and at rest. TLS 1.2+ everywhere; storage encrypted at the platform layer.
Workspace isolation. Every record carries a workspace identifier and every query is scoped to it, including the endpoints that act on a single record — so a guessed identifier from one account cannot reach another's data.
Password handling. Passwords are hashed with scrypt at OWASP's recommended parameters — N=131072, r=8, p=1 — each with its own random salt, and are never stored or logged in any recoverable form. Verification is constant-time, and we enforce a 10-character minimum and refuse passwords that appear in known breach corpora. scrypt is memory-hard: each guess needs 128 MB of memory as well as time, which is what makes it expensive to attack with the graphics cards that make ordinary password cracking cheap. Accounts created under our earlier scheme are upgraded automatically the next time their owner signs in.
Your account does not exist until you prove the address is yours. Signing up records a pending registration and emails you a link; the account, the workspace and the session are created when you click it. That removes a whole class of attack rather than defending against it — nobody can register an account on your email address, set a password on it, and wait for you to sign up and adopt it.
Automated sign-in attempts are challenged. Login, signup, password reset and the contact form sit behind a privacy-preserving bot challenge as well as rate limits, so working through a list of leaked passwords costs more than it returns. The limits count against the account being tried as well as the address it is tried from, because an attacker with a pool of addresses defeats an address-only limit by changing address — and repeated failures for one account are slowed progressively rather than locked, for minutes, never permanently. Password reset is counted separately from sign-in, so somebody deliberately burning your sign-in attempts cannot also close the path you would use to get back in.
Two-factor authentication. Three options: passkeys (Face ID, Touch ID, Windows Hello or a hardware key), an authenticator app, or a code emailed to you. Passkeys are the strongest and the only phishing-resistant one, because the signature is bound to closerev.com. Emailed codes are the weakest — anyone who reaches your mailbox reaches the code — and we say so where you turn them on. Single-use recovery codes cover a lost device. Once any factor is on it applies to every way into the account, including "Sign in with Google": a second sign-in route is not a way around it. A workspace owner can also require two-step verification of everyone in the workspace, so nobody reaches its data on a password alone. Adding a method needs one you already have, and we email you when one is added. Otherwise somebody who got hold of a device you were signed in on could add their authenticator and keep access even after you changed your password. The notice goes to your address rather than to the screen of whoever did it, and it carries a link that signs out every device including theirs. Methods can be added but not removed. Somebody who got hold of a device you were signed in on would otherwise remove the methods they don't have and keep the one they do — leaving your account protected by exactly the thing they stole. Lost a device? Change your password, which signs every other session out immediately, then ask us: we verify who you are and remove the method, and that reset is recorded in the tamper-evident log below.
The riskiest actions ask again. Closing your account, changing your password, exporting everything, or changing a workspace-wide security setting require you to prove it is still you — the code from your authenticator app where you have one, your password otherwise. A session cookie says somebody signed in; it does not say the person at the keyboard is still you, and for these few actions that difference is the whole question. For most of them the proof lasts 30 minutes, so a run of admin work asks once. Turning a workspace-wide requirement on or off — two-step verification, single sign-on — asks every time, in both directions: a setting that lowers what it takes to reach your data should never ride on a proof given for something else.
Single sign-on. Enterprise and Agency workspaces can require everyone to sign in through their own identity provider over OpenID Connect. A domain has to be proven in DNS before it can be used, so nobody can configure single sign-on for a domain they don't control. Once it is required, passwords and Google sign-in stop working for that domain — with one deliberate exception, the workspace owner, so a misconfigured provider cannot lock a company out of its own data. Sessions created this way last a week rather than a month, because single sign-on does not by itself revoke access when someone leaves. The client secret you give us is encrypted before it is stored.
Sessions. Opaque, expiring tokens in httpOnly, Secure, SameSite cookies carrying the __Host- prefix, which stops any other site on a neighbouring domain from writing a cookie our servers would read as yours. They are revocable server-side, and changing your password invalidates every other session immediately. Requests that change something must originate from CloseRev itself; a form on somebody else's site posting to ours is refused before it reaches your data. Session tokens are stored only as a hash, so a copy of our database could not be used to sign in as anyone. A session ends after 30 days, or after 7 days without use. And when your account is signed in from a browser we have not seen before, we email you — with a link that signs out every device if it wasn't you.
Email links. Verification and reset links are single-use and expiring, and we store only a SHA-256 hash of each token — a database leak wouldn't yield working links. Single-use is enforced by the database in one step, so two clicks arriving at the same instant cannot both succeed.
Payments. Card details go directly to Stripe and never reach our servers, keeping us out of scope for handling card data.
Audit log. Uploads, matches, review overrides, exports and deletions are recorded per workspace. Separately, every time someone at CloseRev opens an internal console that can see your account, that is recorded too — who, what they looked at, and when. We keep that record for 24 months, in our database, and a copy made every night is kept for up to 6 years in storage that cannot be altered, so the question "did anyone look at this?" stays answerable for longer than any plan keeps your data. Those entries are chained: each one is sealed with a hash covering the entry before it, and the database refuses to change or reseal a sealed entry. Removing or editing an entry after the fact breaks the chain at that point, and a check that runs nightly reports where. A copy of the chain's newest seal is also written every night to a store held under separate credentials, so the log and its own record cannot be rewritten together.
Real deletion. Deleting an import removes its records, its match results and the original uploaded file from storage — not just a row flag.
Exports are safe to open. A spreadsheet treats a cell beginning =, +, - or @ as a formula to run, so a value someone put in a CSV you uploaded could otherwise become a command on the machine of whoever opens your export. We neutralise those cells in a way that survives the file being saved and reopened, and we leave ordinary numbers and negative amounts alone.

Data minimization

Matching needs a phone number or an email address, and an amount. You choose which columns to map, and we'd rather you uploaded fewer. Special-category data is out of scope entirely — see the Acceptable Use Policy.

We do not sign business associate agreements (BAAs) under HIPAA, so do not upload protected health information — a diagnosis, a treatment, insurance details or an appointment tied to a patient. A sale record with a name, phone number, email address, amount and date for a service that says nothing about anyone's health is fine; if you are a health provider, leave out anything that reveals a person's health.

What we have not done yet

We would rather say this plainly than let a trust page imply more than is true:

No SOC 2 or ISO 27001 certification. We're an early-stage product and haven't been through an audit.
No customer-configurable data residency. Storage region is currently platform-default.

If any of these is a blocker for your procurement process, tell us — it's useful for us to know which one to do first.

Who at CloseRev can see your data

Nobody, in the normal course. The product is self-serve and support does not require reading your records. There is no "log in as this customer" feature and no impersonation, deliberately — the moment one exists it becomes the shortest path to every customer's data.
The internal console cannot read your uploaded records at all. It shows account and billing information and counts of what you have processed. It has no access to the sales or lead records themselves.
Reads are logged, not just writes. Anything an administrator looks at is recorded with who, what, when and from where. If you ever ask who at CloseRev looked at your account, the answer comes from a record rather than from memory.
Access needs single sign-on with multi-factor. The console sits behind Cloudflare Access and additionally checks the verified identity against an allowlist, so there is no password of ours that could be phished into it.
Mail you send us. Mail to support@ becomes a case in our own console, and its attachments are kept with the case in our own storage and deleted with it after 24 months. Our team's mailbox receives a copy of the sender, subject and text of each message sent to a closerev.com address — never the attachments.

How we test what we ship

Four checks run against the code on every change, because reasoning about isolation is not the same as verifying it:

Every query that touches customer data is enumerated and reviewed. A check extracts each statement and holds a reviewed baseline, so a new or rewritten query that is not scoped to a workspace has to be looked at rather than blending in.
Isolation is tested over real HTTP, not reasoned about. Three separate workspaces are created in a real copy of our runtime, and every endpoint that accepts an identifier is asked for another workspace's data — through the same code the site runs, with the same database, storage and session bindings. A test that has no way to fail is worthless, so each of those runs alongside a control proving the rightful owner still gets their data.
Pages are measured in a browser, not eyeballed — our public pages, in light and dark, at desktop and phone widths, for overflow, clipping and contrast, automatically whenever a change touches what they show; the signed-in pages the same way when we run the audit with a test account.
Database changes are applied by a runner that keeps a ledger, which refuses to apply anything twice, out of order, or where the recorded history and the code no longer agree.

A written security review covering tenant isolation, authentication, uploads, billing, public tokens and data lifecycle is a condition of general availability. It has been run repeatedly, most recently as two dedicated passes before launch, including a read-only check of the live payment configuration, and inside a real copy of the runtime we deploy to. Both reports record what was not proven as plainly as what was.

Backups, retention and deletion

You set the retention window per workspace, within what your plan keeps. A nightly job deletes imports past it — the records, the match results and the original CSVs in object storage — and writes what it did to your workspace's own activity log.
Deleting means deleting. Removing an import removes its records and files. Closing your account removes the account and, where you own it, the workspace and every file belonging to it. Invoices are kept only where tax law requires.
Backups are the platform's, with point-in-time recovery covering the last 30 days of the database. They are for recovering from our failure, not a second copy you can query.
A restore cannot quietly undo a deletion. This is the one place where "deleting means deleting" needed more than a delete: rewinding the database to recover from some unrelated fault would otherwise bring back everything removed since, and nobody would know. So every deletion is recorded — what was removed, for which workspace, when, and why, with none of the data itself — and re-applying those records is a step of our restore procedure rather than something to remember. Uploaded files are not covered by that rewind at all; once a file is deleted from object storage it is gone.

If something goes wrong

Personal-data breaches: we notify affected customers without undue delay and within 72 hours of becoming aware, with what we know and what we are doing. That commitment is contractual — it is in the DPA, not just here.
Outages affecting data integrity or access: we email workspace owners rather than waiting for anyone to check a page, and again when it is resolved. Component health is published on our status page, which measures rather than being updated by hand.

Why this page is specific

Naming the algorithm and its cost parameters is deliberate, and it is what security standards ask for rather than something we get away with. A system should be secure when everything about it except the keys is public — that principle is older than the industry, and it is why NIST publishes its cryptographic standards openly rather than describing them vaguely. A design that only holds while nobody knows how it works is not a design that holds.

What you will not find here is anything that is actually a secret: no software versions or patch levels, no internal hostnames or network layout, no key material, and no thresholds an attacker could tune against — how many attempts trigger a lockout, or how long a rate limit lasts. The numbers on this page are commitments we are making to you, not settings you could aim at.

If you are evaluating us and something here is not specific enough to answer your question, ask. We would rather write it down than have you guess.

Reporting a vulnerability

Email security@closerev.com, or read the machine-readable version at /.well-known/security.txt. We acknowledge within 2 business days, tell you whether we have reproduced it within 10 business days, and keep you updated until it is closed. We ask for 90 days before public disclosure, and less if the fix ships sooner.

Please don't access, modify or keep data that isn't yours, don't run automated scanning that degrades the service for customers, and don't social-engineer our staff or our vendors. Within those limits we will not pursue researchers acting in good faith, and we will credit you if you would like us to.

Cookie preferences