Security

Security Overview

Controls we operate today, described without embellishment.

This page is maintained by StrivePoint Solutions to answer common security questions about our platform. It describes controls that are implemented in the running product. It is not an audit report, a certification, or an independent verification of any kind.

Tenant authorization

Client data is partitioned by account. Requests carry an authenticated identity, and queries are constrained to the account that identity belongs to. These tenant, role, and row-level controls are designed to prevent unauthorized access between client accounts.

Role-based access

Portal capabilities are gated by role. Roles are stored separately from user profiles and are evaluated server-side; a browser cannot assert its own role. Membership status is checked on every access path, so a suspended user loses access immediately.

Row-level security

Database tables holding client data have row-level security enabled with policies scoped to the requesting user's account and role. Privileged server operations are separated from ordinary reads and run only after the caller's authority is verified.

Authentication

Accounts are provisioned through an approval process rather than open self-registration. Sessions are managed by our authentication provider, and password reset is email-verified. Multi-factor authentication is not currently enforced for all accounts.

Encryption in transit

All website, portal, and API traffic is served over HTTPS/TLS.

Credential handling

Third-party credentials, including mailbox authorization tokens, are encrypted at rest using authenticated encryption with a server-held key and are never exposed to browser code. Provider secrets are held in the server environment, not in application source.

Private storage

Uploaded documents are stored in non-public buckets. Access is granted through short-lived, authorization-checked links rather than public URLs.

Logging and audit

Authorization changes, campaign authorization, suppression changes, administrative actions, and security events are recorded in append-only tables. Logs are written to exclude credentials and token material.

Backups

Our managed database provider performs routine backups of production data.

Secure development

Changes are reviewed before release and covered by an automated test suite that includes tenant-isolation and suppression regression tests. Dependency and platform security scans are run against the codebase.

Incident response

We investigate suspected incidents, contain and remediate, preserve relevant evidence, and notify affected clients where notification is warranted or legally required.

Vendor management

StrivePoint uses third-party service providers to host, secure, operate, and support the platform. Additional provider information may be included in the applicable customer agreement or provided to authorized customers upon request. We review a provider’s stated security and data-handling terms before adopting it.

Data retention

Retention is governed by an internal matrix that separates legal evidence, raw content, operational records, security logs, financial records, and backups, with legal holds overriding routine deletion for the records they cover. See our Privacy Policy.

Client responsibilities

  • Managing who is invited to the account and removing users promptly.
  • Protecting credentials and using unique passwords.
  • Uploading only data the client is authorized to process.
  • Configuring campaign, suppression, and sharing settings correctly.
  • Reporting suspected compromise without delay.

What we do not claim

StrivePoint does not hold SOC 2, ISO 27001, PCI DSS, or HIPAA attestation, and we make no such claim. We do not offer end-to-end encryption, we do not guarantee isolation, we do not operate 24/7 staffed monitoring, and we have not published third-party penetration test results. No system can be guaranteed secure.

Reporting a vulnerability

Report suspected vulnerabilities to management@strivepointsolutions.com. Please include enough detail to reproduce the issue, and do not access, alter, or exfiltrate data belonging to anyone else while testing.

Effective July 29, 2026 · Last updated July 29, 2026 · Last reviewed July 29, 2026 · Version 2026-07-29.1