Security overview

Each paying customer receives a dedicated application instance and a dedicated PostgreSQL database. Customer data does not share a database with other tenants. Instances run as containers on our infrastructure behind a reverse proxy that enforces HTTPS. Each tenant runs on its own isolated network segment, so a tenant instance cannot reach another tenant’s instance or our control plane over the network.

Data flows between Vectis and the third-party systems you connect (PSA, RMM, backup, billing) happen either on a scheduled sync (reading) or on an action you explicitly authorise (writing). Every write-back is recorded in an append-only audit log with the originating user, rule, payload, and response.

• In transit. All traffic to and from the Service is served over HTTPS with TLS 1.2 or newer, including the internal connection between each application instance and its database. HSTS is enforced on every domain.
• At rest. Integration credentials (PSA / RMM / billing API keys, OAuth refresh tokens) are encrypted with AES-256 using a key held outside the database and supplied to the application at runtime. Database disks are encrypted at the storage layer.
• Secret handling. Application secrets — database credentials, encryption keys, and integration API keys — are delivered to running services as mounted files, not baked into container images or exposed in the process environment.
• Passwords. User passwords are hashed with bcrypt at a cost factor of 12 or higher. Plaintext passwords are never logged or persisted.
• Sessions. Session cookies are HttpOnly and Secure, with an 8-hour inactivity expiry. Sign-in is rate-limited (5 attempts per 15 minutes per identifier). The MSP-staff session cookie is SameSite=Lax so that signed OAuth callbacks (e.g. QuickBooks) can complete; the customer-portal session cookie is SameSite=Strict. Both states defend against cross-site POST CSRF.

Role-based access control is enforced server-side on every authenticated route — the client UI is not trusted. The default roles are admin, analyst, and viewer, each with a declared permission surface. Admin actions — user invitations, role changes, integration writes, and rule edits — are recorded in the audit log.

Our own production access is restricted to named personnel via SSH key and is reviewed whenever personnel changes. The application itself connects to each database with a least-privilege, non-superuser role that cannot run server-side programs or read other database roles’ data; elevated credentials are reserved for maintenance. We do not access tenant databases except to operate, support, troubleshoot, or secure the Service — each such access is logged.

• Every API route validates its input with a strict Zod schema at the boundary.
• All SQL is parameterised through Drizzle ORM — no string concatenation of user-controlled values.
• The in-product query builder operates against a frozen column allowlist, not a dynamic schema inspection.
• Output is escaped by React’s built-in rendering; we do not use dangerouslySetInnerHTML.
• Integration credentials are never logged, not even partially.

The rules engine can write back to your connected systems. To keep that power safe:

• every write-back action is logged with its full payload, recipient system, result, and originating rule;
• new rules must be tested in dry-run mode before they can be enabled to fire against live systems;
• per-integration rate limits stop runaway rules from flooding a provider;
• failed actions land in a dead-letter queue for manual inspection instead of retrying indefinitely.

Customer databases are backed up on a nightly schedule with a rolling retention window. Backups are encrypted and stored in a separate location from the live database, and the key needed to decrypt the off-site copy is held outside the production environment. Integrity is verified weekly by a restore-into-scratch-database check, and we periodically rehearse a full recovery from the off-site copy into a clean environment; both results are recorded to a log. Our target recovery objectives are an RPO of 24 hours and an RTO of 4 hours for a single-instance restore.

We maintain a written incident-response runbook that covers severity classification, customer communication, mitigation playbooks, and post-incident review. Live operational status is published at mspvectis.com/status.

If we learn of a security incident affecting customer data, we will notify affected customers without undue delay, provide the information available to us about scope and remediation, and — where law requires — notify the relevant supervisory authority within statutory deadlines (GDPR: 72 hours).

Vectis is a young product and we are honest about what that means:

• SOC2. Controls are modelled on the SOC2 Trust Services Criteria (Security, Availability, Confidentiality). We do not yet hold a SOC2 report. The audit decision will follow customer demand; we will publish the target timeline here when one is set.
• GDPR / UK GDPR. We act as a processor for the customer data you route through the Service; you remain the controller of data about your end customers and employees. Our Data Processing Addendum, when executed, governs that relationship. EU-to-US transfers rely on the Standard Contractual Clauses.
• HIPAA / PCI DSS. Vectis is not designed as a destination for protected health information or cardholder data and we do not sign business associate agreements at this time. Billing is handled by Stripe, a PCI DSS Level 1 provider; card data never reaches our systems.

We publish the list of third-party services that process data on our behalf — cloud hosting, payments, transactional email, error tracking — and the purpose and jurisdiction of each, on our sub-processor list. Application dependencies are pinned via lockfile; new direct dependencies are reviewed before introduction.

If you believe you have discovered a security vulnerability in Vectis, please report it privately to security@mspvectis.com. We commit to:

• acknowledge the report within 3 business days;
• keep you informed of our progress toward a fix;
• not take legal action against good-faith researchers who follow responsible-disclosure practices.

No security program is perfect. We favour simple, auditable controls over extensive process. If a specific control in your own framework requires a deeper discussion than this page provides, email security@mspvectis.com and we will respond with the detail you need.