Security is the default, not the upsell.
The 60-second version
No security team on staff? Start here.
Most MSPs your size are their own security team. So here’s the whole page in four plain sentences — what actually protects your customers’ data when it runs on Vectis. Everything below backs each one up, and the procurement-grade detail is one click away if your team wants it.
Your data is never mixed with anyone else's
Every MSP gets its own separate database — not a shared one filtered by a column. Another tenant's bug or breach has no path to your customers' data.
The keys to your customers' systems stay locked
Every credential you connect is encrypted, the key to unlock it is held off the database, and none of it is ever written to a log.
Nothing happens without a record
Every write-back, every rule, every login lands in a log the app itself can't erase. If something changes, you see who, what, and when.
You don't pay extra for any of it
No 'enterprise security' tier. Isolation, encryption, MFA, and the audit log ship on every plan — including Starter.
Security & isolation
The headline posture.
Three claims that ship by default on every tenant. Each one expands into a full section below, with the control that backs it.
Per-tenant Postgres
Every workspace gets its own database. No shared rows, no shared schemas, no noisy-neighbor query plans.
AES-256 credentials
Integration secrets are encrypted at rest with a key held outside the database. Stored, rotated, and audited.
MFA on every staff account
Operator MFA is enforced by default — TOTP and WebAuthn. Sessions are HttpOnly, Secure, SameSite-strict, with 8-hour inactivity expiry.
01
Tenant isolation
Each MSP is its own container, database, and subdomain.
Multi-tenancy in Vectis is a deployment boundary, not a query filter. We don’t branch on tenant ID inside a shared application — each paying MSP is provisioned as its own application container talking to its own PostgreSQL database under its own subdomain. A bug in one tenant’s sync, a misconfigured rule, an accidental cross-customer query — none of those have a path to another tenant’s data, because the rows are in a different database with different credentials behind a different network policy.
Own application container. Each tenant runs in a dedicated Docker container with its own scheduled jobs, its own background workers, and its own process boundary. Restarting one tenant’s container does not touch any other tenant.
Own PostgreSQL database. Customer data lands in a per-tenant database with a per-tenant role and password. The application connection string is unique per container — there is no shared pool that gets re-bound at request time, and no fallback path to a multi-tenant table.
Own subdomain. Every tenant is reachable under <your-msp>.mspvectis.com with its own TLS certificate. Session cookies are scoped to the subdomain so a leaked cookie cannot replay against another tenant.
Hub vs. tenant separation. Account, billing, and provisioning state lives in a separate hub database. Tenant databases never see other tenants’ billing or operator records. The hub never holds customer integration data.
02
Credentials at rest
AES-256, key outside the database, never in a log.
When you connect ConnectWise, NinjaOne, Microsoft 365, or any other vendor, the API key or OAuth refresh token is wrapped in AES-256-GCM before it touches the database. The encryption key lives outside the database — it’s supplied to each tenant container at runtime via an environment variable and is not stored on the same disk as the data it protects.
Threat model. If a tenant’s database dump leaks — backup misconfig, insider mistake, cloud-provider compromise — the integration credentials inside it remain ciphertext. The key required to decrypt them is in the running container’s environment, not on the same volume. An attacker would need running-process access to recover the plaintext, not just disk access.
Same envelope for every secret. Integration credentials, SSO client secrets, SAML signing certs, MFA TOTP secrets, and webhook signing keys all use the same AES-256-GCM helper. There is no second-class storage path for any of them.
Never logged. The application logger redacts credential fields at the boundary. Stack traces never include raw token values. Request bodies that carry credentials are filtered before they reach the error tracker.
What gets encrypted
- Integration API keys & OAuth refresh tokens (every PSA, RMM, backup, billing, documentation, distribution connector)
- SSO client secrets and SAML certificates
- MFA TOTP shared secrets
- Webhook signing secrets
- Customer portal share tokens and signed download URLs
AES-256-GCM, 96-bit IV, 128-bit tag
03
Authentication
Bcrypt, rate-limited sign-in, MFA required, optional SSO.
Every operator account is MFA-required at first login. Passwords are hashed with bcrypt at cost factor 12 or higher and rate-limited at the sign-in endpoint. Paid tiers can layer SSO on top — generic OIDC or SAML, so any IdP your team already runs is a candidate.
Passwords
Bcrypt cost factor 12 or higher. Plaintext passwords are never persisted or logged. SSO-only accounts get a random unusable hash so the password column never holds a usable secret.
Sessions
HttpOnly, Secure cookies with an 8-hour inactivity expiry. Operator cookies are SameSite=Lax so OAuth callbacks (e.g. QuickBooks) can complete; portal cookies are SameSite=Strict. Both states block cross-site POST CSRF.
Rate limiting
5 failed sign-in attempts per 15 minutes per identifier triggers a temporary block. Repeated failure surfaces in the audit log so a brute-force attempt is visible to the operator team.
MFA
TOTP plus single-use recovery codes, enforced at first login for every operator account on every plan. No opt-out. The secret is encrypted at rest with the same AES-256 envelope as integration credentials.
Single sign-on (paid tiers)
Bring your own IdP via OIDC or SAML.
Vectis does not hard-code a vendor list. The SSO surface speaks two open standards — generic OIDC and generic SAML 2.0 — so any identity provider that emits compliant assertions is supported. That covers the IdPs MSPs actually run:
- Microsoft Entra ID (Azure AD) — OIDC or SAML
- Okta — OIDC or SAML
- Google Workspace — OIDC
- JumpCloud — OIDC or SAML
- Duo / Cisco Secure Access — SAML
- OneLogin, Ping, ADFS — SAML
Enforcement mode locks password login for a configured domain so SSO becomes the only path in. A break-glass admin exemption exists for IdP-outage recovery; the break-glass account still requires bcrypt + TOTP — one factor is never enough.
04
Audit trail
Every write recorded, append-only, the application cannot delete.
The rules engine can write back to your PSA, RMM, and billing systems. That power needs an audit trail. Every write-back, every rule execution, every admin action, every authentication event lands in an append-only log the application layer has no delete path against — the only way a row leaves the audit log is via direct database access, which is itself logged at the host layer.
What ends up in the log
Action, actor, target, payload, response, IP, timestamp.
The audit log is a single append-only table that records every state-changing event in one shape: who did what to which target, what payload they sent, what response the downstream system returned, where they came from, and when. The filter chips above the table let security reviewers slice by action type, actor, target, or date range — the same surface a SOC analyst would expect on a SaaS admin console.
Categories: integration write-backs (ticket created, alert acknowledged, billing line added), rule executions (dry-run + live), admin actions (user invited, role changed, integration credential saved), authentication events (login success, login failure, MFA enrolled, SSO redirect), and security-relevant runtime events (rate-limit trip, SSO-enforced password attempt blocked).
Failed rule actions land in a dead-letter queue with the originating payload preserved so the operator team can replay or discard with full context.
05
Infrastructure
Hardened host, HTTPS by default, intrusion detection on.
The host these tenants run on is hardened with two cooperating layers — AWS GuardDuty watching the network plane (VPC flow logs, DNS, CloudTrail) and OSSEC HIDS watching the host plane (file integrity, rootkits, log signals, container changes). Caddy terminates TLS for every subdomain. Containers run as non-root. The database is not publicly reachable.
TLS by default
Caddy auto-issues a certificate per tenant subdomain via ACME and enforces HSTS. TLS 1.2+ only. HTTP redirects to HTTPS at the edge — there is no plaintext path into the application.
Security headers
Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security, Permissions-Policy applied at the framework layer on every response.
Container hardening
Application containers run as non-root with a read-only base. The Postgres container binds to localhost only; nothing on the public internet can reach the database port directly. Lockfile-pinned dependencies, no wildcards.
GuardDuty
AWS GuardDuty monitors VPC flow logs, DNS queries, and CloudTrail API calls in the production region. Detects port scans, outbound C2 traffic, crypto-mining DNS, suspicious IAM activity.
OSSEC HIDS
File-integrity monitoring on /etc, /usr/bin, /boot, and the application directory every six hours. Rootkit scanning, journald log analysis, automatic IP blocks via iptables on level ≥ 6 alerts, container-status monitoring.
Encrypted backups
Nightly database dumps, encrypted, stored separately from the live volume, 7-day retention by default. Weekly restore-into-scratch verification against a rotating tenant so a backup that has never been restored is not the recovery plan.
Recent independent penetration testing exercised the authentication surface, the integration credential layer, the rules engine, and the public marketing tree. Findings landed in the issue tracker, were remediated, and were re-tested. High-level outcomes inform the controls listed above; raw findings are shared under NDA with procurement reviewers on request.
06
Rules-engine safety
Dry-run first, rate-limited per integration, failed actions queued.
A rules engine that can create tickets, acknowledge alerts, add billing lines, and update PSA records is powerful enough to do damage at scale. Four guardrails sit between an enabled rule and a runaway loop.
Dry-run required
Every new rule starts in dry-run. The engine evaluates triggers and records what it would have done, without dispatching to the downstream system. Only after an operator promotes the rule does it write to real systems — and the promotion itself is logged.
Rate limits per integration
Each connector has a ceiling on actions per minute and per hour, scoped to the rule that issued them. A misconfigured rule that tries to create 10,000 tickets in a loop hits the ceiling and stops; it cannot exhaust your vendor’s API quota.
Dead-letter queue
Failed actions — 4xx/5xx from the vendor, credential expired, validation rejected — land in a dead-letter queue with the originating payload preserved. The operator team can inspect, replay, or discard with full context; failures don’t silently retry forever.
Every action logged
The full request payload and the vendor’s response are recorded alongside the rule that fired and the operator who promoted it. A surprise write in your PSA is always traceable to a specific rule, a specific actor, a specific moment.
07
Sub-processors
Named, scoped, and notified 30 days before material change.
A short list of third-party services process customer data on our behalf. Each one has a clear purpose, a clear data scope, and a clear jurisdiction. We do not add a new sub-processor that touches customer data without 30 days’ notice.
Amazon Web Services (AWS)
Cloud hosting — VPS compute, EBS storage, network plane (GuardDuty)
United States
All customer data at rest; processed only inside the production VPC
Cloudflare
DNS, edge proxying for the marketing surface, DDoS protection
United States
DNS records and HTTP metadata for marketing pages; never proxies tenant subdomain traffic by default
Stripe
Subscription billing — payment method, invoice issuance, plan state
United States (PCI DSS Level 1)
Billing identifiers; card data never reaches Vectis systems
SendGrid (Twilio)
Transactional email — login codes, password resets, weekly digest, billing receipts
United States
Operator email addresses and the contents of transactional messages
Sentry
Application error tracking — exception capture for triage
United States
Stack traces and request metadata with credential fields filtered at the boundary
Material changes — adding a new sub-processor that handles customer data, or moving an existing one to a different jurisdiction — are emailed to billing contacts at least 30 days before the change takes effect. The clause-by-clause procurement version of this list, including SCCs governing EU-to-US transfers, lives at /legal/security.
08
Reporting a vulnerability
security@mspvectis.com — acknowledged within three business days.
If you believe you have found a security issue in Vectis, send it privately to security@mspvectis.com. We acknowledge every good-faith report within three business days and never pursue researchers who follow responsible-disclosure practice.
Scope. The Vectis marketing surface (mspvectis.com), every tenant subdomain, the customer portal, and the public MCP endpoint. Out of scope: third-party services we depend on (report those to the vendor), social engineering of our operators, and physical attacks against the host.
What we ask. Give us a clear reproduction, do not exfiltrate data beyond what is needed to demonstrate the issue, do not disrupt service, do not access other tenants. Coordinate disclosure — give us a reasonable window to fix before publishing.
What we commit to. Acknowledge within three business days. Triage within five. Fix or formally accept the risk within thirty for any finding that touches customer data, authentication, or the audit trail. Notify affected customers without undue delay if a finding is confirmed to have exposed data, with statutory 72-hour authority notification where it applies under GDPR.
Bug bounty. No formal program at this stage — the budget for one will ship when it is fundable as more than a token gesture. Until then, the disclosure channel is real, responses come from a human, and recognition in our security acknowledgements is offered on request.
security@mspvectis.com
Encrypted reports welcome — request our PGP public key in the first message and we’ll route the response accordingly.
Response window — 3 business days
09
Compliance & certifications
No SOC 2 today. Compensating controls listed above, procurement documents linked below.
Procurement teams open a security page and scan for badges before reading anything else. The honest list below covers what we hold, what we don’t, and the compensating control behind each gap. The four documents your security team will ask for are linked alongside; standardized questionnaires (SIG, CAIQ, Vendorpedia) return completed within five business days.
SOC 2
We do not hold a SOC 2 Type II report and are not currently pursuing one. At our scale, the multi-month, six-figure audit budget is better spent on the controls themselves than on certifying them. The controls a SOC 2 audit tests are described in sections 01–08 above: per-tenant database isolation, AES-256-GCM credentials at rest with the key held outside the database, MFA-required staff accounts, append-only audit log on every write, OSSEC + GuardDuty host monitoring, and encrypted nightly backups. For your procurement file: this is a “not yet, here are the compensating controls” answer — quotable as such. We will publish a target audit date when one is committed to; we do not list one today.ISO 27001
No certification today, no current timeline. Our internal security program is documented and reviewed against the same controls in sections 01–08 above. Listed here so you can record it as not-claimed in your vendor review.GDPR / UK GDPR
We act as a processor for the customer data you route through Vectis; you remain the controller for data about your own end customers and employees. Our Data Processing Addendum governs the processor relationship; EU-to-US transfers rely on the Standard Contractual Clauses incorporated by reference into the DPA. The full sub-processor list lives at /legal/sub-processors.CCPA
Vectis is a service provider under the California Consumer Privacy Act. We do not sell personal information and do not retain, use, or disclose customer data outside the scope of the contracted services. Consumer rights requests (access, deletion, opt-out of sale) route through your MSP, who is the business under CCPA; mechanics are detailed in our Privacy Policy.HIPAA / PCI DSS
Vectis is not designed as a destination for protected health information or cardholder data. We do not sign Business Associate Agreements at this time. Billing is handled by Stripe (PCI DSS Level 1); card data never reaches Vectis systems.
Procurement checklist
The four documents your security team will ask for, linked here so you don’t have to ask:
Standard questionnaires
SIG, CAIQ, Vendorpedia, or your own — completed on request.
Email security@mspvectis.com with the questionnaire attached. A completed response returns within five business days, signed under NDA where required.
Response window — 5 business days
For procurement reviewers
The clause-by-clause version.
Every control above mapped to specific commitments plus the legal basis for them. Aimed at procurement and security reviewers, not buyers — but linked from here so the path is obvious.