Built so it can’t be the weak point.

Your login. VERUS connects to each system with a read-only login that your team creates and controls. We publish the exact script for each kind of database on Connecting VERUS. Switch it off and VERUS stops reading.

No way to write. VERUS’s connectors have no write, update, delete or create function at all. It is not a setting someone can turn on.

Every statement checked. Before any statement leaves VERUS for one of your systems, it is checked to be one plain read (a single SELECT) and nothing else: no changes, no commands, no tricks hidden in functions. 76 hostile test cases prove the check refuses them. For a database, the Setup screen lists every table VERUS will read and every kind of statement it will send, so whoever approves access can see it first.

When someone asks a question, VERUS answers it from its own copy of the data, on its machine, never by sending a query to your ERP. Every answer is a single read, limited in time and size, and narrowed to the companies, sites and subjects that person may see before it runs. A plant manager’s question can only ever see their plant. Over 300 automated tests hold those lines: a guard corpus of 104 hostile queries and 198 tests of each person’s access.

Nothing, by default. Each of these is off until an administrator turns it on:

That is the whole list. VERUS has no telemetry, no usage reporting and no update check. It never calls home, and we never connect to it. Turn the model off and VERUS still runs: dashboards, agents, the morning brief and the data findings all work without one.

• Passwords for your systems are stored encrypted, with a key that stays on your machine or in your own secrets store.
• People sign in with passwords stored only as strong one-way hashes (argon2id), sessions that expire, protection against repeated guessing, and each person’s access set by role.
• Every VERUS process runs unprivileged, never as the machine’s all-powerful user.
• The browser is locked down: VERUS cannot be framed by another site, runs only its own code, and stays on https once you serve it that way.
• Logs carry no data values. Anything that looks like a value is scrubbed from error messages before it is written.
• About 650 automated security tests cover read-only, each person’s access, sensitive columns, the query guard and notifications. Most run automatically on every change, with every dependency checked against the known vulnerability databases; all of them run before each release.

Security is shared. VERUS does its part; these are the parts only your team can do, and they are short:

• Create a read-only login for each system, as narrow as you like.
• Serve VERUS over https with a certificate your devices trust.
• Keep the VERUS machine’s disk encrypted and backed up, like any server holding business data.
• Let only your own people reach it.

The full list, step by step, is on Connecting VERUS.

We would rather tell you than have you find out.

• We are not SOC 2 audited. SOC 2 is an independent audit of how a vendor runs over months, and VERUS is new. Because VERUS runs on your machines and we never hold your data, most of what an audit protects is already in your hands. We will begin a SOC 2 audit when a customer needs it, and until then we answer your security questionnaire in full.
• Single sign-on and two-factor sign-in are designed for and not yet built. People sign in with a password.
• No independent penetration test yet. We plan one before VERUS runs at its first companies, and will share the summary.

If you believe you have found a security problem in VERUS or this site, write to contact@resonanceinstitutellc.com with “Security” in the subject. We will acknowledge it within two business days, keep you informed while we fix it, and credit you if you wish. Please give us a reasonable time to fix it before telling anyone else, and do not access or change data that is not yours while you look.