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.

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. 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.
• 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, Secure, SameSite=Strict, with an 8-hour inactivity expiry. Sign-in is rate-limited (5 attempts per 15 minutes per identifier).

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, uses least-privilege service accounts for database access, and is reviewed whenever personnel changes. 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. Integrity is verified weekly by a restore-into-scratch-DB check; the result is 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. Vectis is operated by a small team; 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.