Security · Responsible disclosure

Security & vulnerability disclosure

If you’ve found a security issue in RevenuePoint or anything we run, here’s how to reach us safely. We take every report seriously, respond fast, and credit researchers who help us ship a fix.

Email [email protected]Get our PGP key

How we protect client data.

Least privilege. We ask only for the access the work needs, and we don’t copy client data unless the engagement requires it.
Encrypted in transit and at rest. TLS 1.2 or higher on every connection; databases, disks, and backups are encrypted with keys that rotate automatically.
Each client kept separate. On the RevenuePoint Platform every client’s data sits in its own warehouse schema, read through credentials that see only that client, with row-level security in the application.
Individual accounts and roles. No shared logins. MFA is required on our accounts that touch client systems and available to every platform user.
Locked-down hosting. US-hosted. Databases aren’t reachable from the internet, admin access runs through audited sessions, and daily backups are copied to a separate, locked account.
AI features see what you see. Otto and the AI connector are limited to what the signed-in user can already see. Data reaches a model only when someone asks a question.
Incidents. We contain, notify the affected client, investigate, fix, and send a written summary.

The full policy also covers credentials, devices, retention, subcontractors, and the engagement lifecycle: Data Security Policy (PDF).

How to report a vulnerability.

Email [email protected]. Encrypt with our PGP key if you can — it’s below. Plain email is fine if you can’t. Don’t use [email protected] for security reports; that inbox isn’t monitored for vulnerabilities.

PGP public key.

Use this key to encrypt sensitive details. Verify the fingerprint matches before you trust it.

Fingerprint: A4BD C321 4EF3 EB9F CA6A E7FC D765 B501 DFBD D860
Identity: RevenuePoint Security <[email protected]>
File: revenuepoint.com/pgp-key.asc

What to include.

A clear description of the issue and why it matters.
Reproduction steps — URLs, payloads, headers, or accounts you used. Screenshots are welcome.
Impact — what an attacker could do (data exposure, account takeover, code execution, etc.).
The affected surface (revenuepoint.com, the RevenuePoint Platform, Gateway tenant, NPSP middleware, …).
Optional: a minimal proof of concept. Please don’t exfiltrate live customer data.
How you’d like to be credited — name, handle, or anonymous.

What to expect from us.

Within 1 business day — we’ll reply to confirm we received your report.
Within 5 business days — triage, severity assessment, and a target window for the fix.
Through to resolution — a status note at least every 7 days while we work the fix.
Coordinated disclosure — default 90 days from initial report or fix release, whichever comes first. Credit goes to researchers who follow this policy.

Scope.

In scoperevenuepoint.com and subdomains; the RevenuePoint Platform (portal, reports, and AI connector); Gateway and shipped connectors (Salesforce, SAP, custom REST); npsp-middleware on our supplied images; public APIs at api.revenuepoint.com; authentication, authorisation, tenant isolation, and audit-log integrity; anything that affects customer data confidentiality, integrity, or availability.

Out of scopevolumetric DoS or stress testing; social engineering of staff or customers; physical attacks; spam/phishing without security impact; vulnerabilities in third-party services we depend on (Salesforce, SAP, Stripe, etc.) — please report those to the respective vendor; best-practice findings without demonstrated exploitability (missing headers, version disclosure).

Safe harbor.

We will not pursue legal action against researchers who make a good-faith effort to follow this policy.

That means: report through [email protected]; don’t access more data than necessary to demonstrate the issue; don’t exfiltrate or publicly disclose customer data; don’t degrade service for our customers; give us a reasonable window to ship the fix before publishing.

This policy is intended to be compatible with HackerOne’s safe-harbor language and RFC 9116 (security.txt). If you’re unsure whether something is in scope, ask first.