SECURITY
Security
This is OpsView’s self-attestation of its security architecture, current as of November 2026: OpsView has not had an independent audit or certification, and does not claim SOC 2 or ISO 27001.
Architecture at a glance
OpsView is SaaS only. Nothing is installed on the plant network.
OpsView connects to the customer’s visibility tool — Claroty xDome today — with an API key, and only reads from it. It never writes to the visibility tool, or to any plant device or control system.
The app is hosted on Vercel. Data is stored in a managed Postgres database (Neon) in the AWS Sydney region (ap-southeast-2).
Data protection
- All traffic uses TLS, with HSTS.
- Database storage is encrypted at rest by the provider.
- The visibility-tool API key is encrypted on the server. Only its last 4 characters are ever shown in the app.
- Point-in-time database restore covers the last 7 days.
Access and identity
Sign-in is through Clerk. Accounts are invite-only. There is no public self sign-up. Roles are admin and user.
Every customer’s data is separated by tenant on every read and write. Automated cross-tenant tamper tests run on each change.
Application hardening
Security headers are set: frame embedding is blocked, nosniff is set, and referrer and permissions policies are strict. A content security policy runs in monitoring mode.
Refresh, upload, and invite actions are rate limited. All input is validated on the server. Error messages shown to users are redacted: no stack traces, keys, or connection strings.
How we build it
The main branch is protected. Every change goes through a pull request with required automated checks: unit tests, and a browser end-to-end suite.
Dependency vulnerability alerts and fixes run automatically.
On our roadmap
These are not done yet.
- Database-level row security, as a second layer of tenant separation.
- An audit log of user actions.
- An independent third-party security assessment.
Report a security issue
Email contact@opsview.si.
The Terms of Use are separate from this page.