OpslyIQ runs payroll estimates, bank balances, and clock-in photos — the most sensitive data a restaurant has. Here's exactly how it's protected, in plain English. Procurement-grade detail and our current SOC 2 status are available on request.
Every restaurant's data is walled off from every other right in the database, using row-level security — a rule the database itself enforces on every read and every write, not something the app is trusted to remember. Even if application code had a bug, the database would still refuse to return another tenant's row. This is the boundary, and it's tested: a dedicated isolation test suite runs on every change that touches it.
Sensitive values — POS and bank API tokens, SSNs, direct-deposit details, face-match consent flags — are written to an encrypted vault (referenced by an ID, readable only server-side) or one-way hashed where the cleartext is never needed. They are never stored as a plaintext column. An automated gate blocks any change that would introduce a plaintext secret column from ever merging.
This is a security decision, not just a product one. OpslyIQ produces an accurate payroll estimate and hands it to your CPA or payroll processor — it does not file taxes and does not move funds. It reads your bank balance (via Plaid) to catch cash skimming; it never initiates a transfer. Staying out of money movement removes an entire category of risk from the system, and keeps us honest about the one thing we do: get the number right.
Access is role- and location-scoped — a manager sees their locations, not the whole org — with deny-by-default permissions checked on the server, never just hidden in the UI. Sensitive actions (secret rotation, auth policy, payroll) require multi-factor step-up re-authentication (TOTP). Administrator rights are a deliberately reduced set (separation of duties — an admin can't run payroll or change security policy), and de-provisioning or a role downgrade revokes active sessions within the next request, not hours later.
Every sensitive mutation is written to an append-only audit log with before/after values and who did it — the record procurement expects, and the one you'll want the day you need to answer "who changed this, and when."
The Manager Copilot runs through a governed gateway: inputs are PII-redacted before they reach the model, queries are read-only and confined to your own data by the same row-level security above, spend is capped per tenant, and every call is traced. The AI can answer questions about your restaurant; it cannot reach another tenant's data or run up a surprise bill.
We're precise about our language here, because over-claiming on sensitive data creates the very exposure we're avoiding. The clock-in photo is a photo on file for manager review — OpslyIQ does not extract face geometry, and we don't call it "biometric." If facial matching is ever enabled, it's gated behind explicit written consent, enforced in code, and reviewed jurisdiction by jurisdiction first. Geofenced clock-in uses precise location, tied to that one purpose — verifying the punch — never described as vague or "approximate." Precise location is sensitive, and we treat it that way.
You own your data. You can export it, and you can ask us to delete it. We do not sell it, and we do not use it to train third-party AI models. It's your business's record of its own operations — we just keep it safe and make it useful. Most of what OpslyIQ processes, it processes on the employer's behalf, so employee data-rights requests route to the employer as the controller — we never unilaterally alter your system of record.
Honestly chipped: two-factor login, role/location access control, and a full audit log ship today. Single sign-on (SAML) and staff-directory sync (SCIM) arrive with the Enterprise track after launch — the code is built; we're completing the live test against a real identity provider before we call it done. SOC 2 Type II is on our roadmap; the technical control evidence (CC6/CC8 — access, encryption, change management) is in progress. Ask us for the current status — we'll tell you where it actually is, not where we wish it were.
The third parties that may process customer data on our behalf. Several are engaged only when you choose to connect them (your POS, your bank):
| Sub-processor | What they handle | Region |
|---|---|---|
| Supabase | Database, authentication, file storage | United States |
| Vercel | Application hosting + CDN | United States |
| Clover / Square | POS data — only when you connect your POS | United States |
| Plaid | Bank connection — only when you connect a bank | United States |
| Anthropic | AI (Manager Copilot); inputs are PII-redacted before they're sent | United States |
| Stripe | Billing + payment processing | United States |
| Resend | Transactional email (invites, alerts) | United States |
| PostHog | Product analytics (cookieless) | United States |
| Places / Maps — address autocomplete at setup | United States |
Found something? We want to hear it. Email security@opslyiq.com or reach us through contact. We'll acknowledge and work it with you — responsible disclosure, no legal threats for good-faith research.
This page describes the product's security posture in good faith and is not a contract. For a Data Processing Agreement (DPA), a completed security questionnaire, or current SOC 2 status, get in touch.