Security & Subprocessors

Our approach

PestMetrics exists because operators trust us with their numbers: revenue, payroll hours, customer balances, and the API keys to the systems that hold them. Protecting that data is not a compliance checkbox for us, it is the product.

We align our controls with the SOC 2 trust principles. A formal SOC 2 Type 2 audit is on our roadmap and will be pursued when a customer requires it. This page describes what we actually do today, including where our controls stop. It is written to answer diligence questionnaires honestly rather than to score well on them.

Encryption

• Traffic between your browser and PestMetrics is encrypted with TLS. So is traffic between PestMetrics and the third-party systems and providers we call on your behalf.
• Integration credentials — API keys, tokens, OAuth grants, and webhook signing secrets — are encrypted at rest with AES-256-GCM. Each ciphertext is cryptographically bound to your company and integration through authenticated additional data, so an encrypted credential taken from the database cannot be replayed against another account.
• The encryption key is held outside the database, so a database compromise alone does not expose credentials. Key rotation is scripted and verifies that every stored record round-trips on the new key before anything is written.
• Data at rest in our managed database and object storage is encrypted by our infrastructure providers.
• Passwords are stored only as salted bcrypt hashes at cost factor 12. We cannot reverse them, and they do not appear in logs.

Where our encryption stops: if you configure an outbound destination yourself — a webhook endpoint, a chat channel, a notification topic — the transport and storage of that destination are governed by whoever operates it. Specify HTTPS endpoints. Notification channel targets such as Discord webhook URLs, Telegram chat IDs, and notification topics are stored as routing addresses rather than as encrypted credentials, so treat them as you would any other shared address: prefer authenticated destinations, and rotate them if a channel is compromised.

Invited users: when an administrator creates an account with a system-generated initial password, that password is delivered once by email and must be changed at first sign-in. Email is not an encrypted channel end to end. Administrators who prefer to avoid this can have the invitee use the password reset flow instead.

Tenant isolation

PestMetrics is multi-tenant. The application is built so that queries for customer data are scoped to the requesting company, and each company syncs with its own API credentials and its own rate budget. We review and test for scoping defects, and treat any lapse as a priority incident. No design eliminates the possibility of a defect, and we do not claim otherwise. One path goes further: the AI analyst runs its queries as a dedicated read-only database role under PostgreSQL row-level security, so the database itself — not application code — enforces the tenant boundary there, and the policy fails closed if the tenant context is ever unset.

Inside your account, access is further constrained by role and by per-user restrictions down to specific branches and specific pages.

Access control

• Role-based access with three roles — Admin, Manager, Viewer — plus optional per-user branch and page restrictions.
• Sessions are signed tokens that expire after 7 days and can be revoked immediately. Signing out revokes the session, and a password change or account deactivation invalidates every outstanding session on every device.
• Multi-factor authentication is mandatory for every Admin account: an admin who has not enrolled is blocked from the application until they do. It is available and recommended for other roles. MFA secrets are stored encrypted.
• New accounts verify their email address before they can sign in.
• Passwords require 12 or more characters, including an uppercase letter, a number, and a symbol.
• Authentication and other sensitive endpoints are rate limited, to blunt credential stuffing and token guessing.

Our own access to your data

You should know this before your diligence team asks. A small number of PestMetrics personnel hold operator privileges that allow them to view customer accounts and to enter an account in the context of a specific user, in order to reproduce a fault, verify a fix, or provide support. Support sessions of this kind use a separate short-lived token that expires after two hours and carries the operator’s identity, so the action is attributable.

Access is limited to personnel with a business need and is subject to confidentiality obligations. We use it to operate, secure, and support the Service, to comply with law, and to act on your instructions — not for any other purpose. If your agreement or policy requires prior notice or approval before support access, tell us and we will accommodate it.

Audit trail

Administrative and configuration actions taken inside the Service are recorded and attributed to the acting user. Audit and synchronization records are retained on a rolling 90-day window and then pruned automatically. Coverage varies by action type and we are extending it over time, so the audit trail should be treated as a strong operational record rather than a complete forensic log of every event. If you need a longer retention window or export of audit records, contact us.

Sign-in history

Every authentication attempt is logged: successful sign-ins, failed passwords, rejected second factors, and attempts against deactivated or suspended accounts, together with the source address and client. Repeated failures against one account or from one address raise an alert to us. The last successful sign-in is recorded against each user, and administrators can review their own company’s sign-in history from the Service. Records are retained on the same rolling 90-day window as the audit trail.

The boundary worth knowing: this is pattern detection, not intrusion detection. A burst of failures is visible. Someone signing in successfully with stolen credentials from a plausible location looks like the legitimate user, and would not raise an alert. That is why multi-factor authentication is mandatory for Admin accounts — it is the control that actually stops the credential, rather than the one that records it.

Your API keys

The credentials you paste are used for one thing: calling those systems on your behalf. They are not logged, are not displayed back after saving, and leave our servers only in requests to the system they belong to. Connection tests run server-side.

Where you use write-back features, writes are narrow, individually audit-logged, and happen only on a person’s explicit confirmation. AI features suggest; deterministic code writes; you confirm.

AI features

Some features — the operations analyst, narrative commentary, and the plain-language question-and-answer view — send data to a third-party language model provider. A request may include your company and branch names, operational metrics, the names of individual service professionals with their performance figures, review content, the question a user typed, and the rows returned by read queries against your own records.

We use these providers under commercial terms that do not permit them to train their general-purpose models on our inputs or outputs. Providers may retain request content briefly for abuse monitoring under their own terms. Model output is advisory and should be verified before it is relied on.

AI features can be switched off for your account. Email us and we will disable them. Your metrics, dashboards, reports, and exports continue to work without them.

Monitoring and reliability

The platform monitors itself and tells us when something is wrong: sync failures, data drift, and process crashes alert the operator within minutes. Every sync run is logged and inspectable.

Nightly self-tests reconcile our stored numbers against your source system and flag drift. Loud when wrong, silent when right: if our numbers stop matching your system of record, we want you and us to know before you notice.

Retention, backups, and getting your data out

• The production database is managed PostgreSQL with automated, encrypted backups. Deleted data may persist in a backup until that backup expires on its ordinary rotation.
• Audit records, sign-in history, synchronization logs, and notifications are pruned at 90 days; API call counters at 30 days; alerts you have read at 90 days. Payment-provider webhook events are kept for the life of the account and deleted with it, so a payment can be reconciled or re-posted; events we cannot attribute to any account are stored without their message body and pruned at 30 days. Account, metric, invoice, and accounts-receivable data is retained for the life of the account. Stored copies of the records we retrieve from your connected systems are de-duplicated to the latest version per record rather than aged out, so apart from the ARR ledger (90 days) they persist for the life of the account. That is deliberate — it is what lets us recompute and reconcile a historical figure without re-querying your source system — but it means those copies, including telematics trip records, remain until the account is deleted.
• While your subscription is active, you can export reports in CSV, Excel, and PDF. If you need data in a form the built-in exports do not cover, or your subscription has lapsed and you need an export, email us and we will provide a reasonable machine-readable export of your data.
• You own your data. On termination, and on request, we delete or de-identify it within 90 days, apart from records we are required to keep — billing and tax records, security and suppression records, and de-identified aggregates. We confirm when deletion is complete.
• We do not sell your data, do not use it for advertising, and do not use one customer’s data to benefit another in identifiable form.

The Privacy Policy sets out retention and deletion in full, including what survives account deletion.

Incident response

If a security incident affects your data, we will notify you without undue delay after becoming aware of it, with what happened, what data was involved, and what we did about it, and we will support your own notification obligations. Report anything suspicious to security@pest-metrics.com.

Subprocessors

This is the current, authoritative list of the third parties that may process data in connection with the Service. Providers marked conditional receive data only if you enable the relevant feature or connect the relevant system. Our Privacy Policy points here as the maintained roster.

Destinations you configure

These are not our subprocessors. They are addresses you enter, and we deliver to them because you told us to. We do not choose them, do not hold a contract with them on your behalf, and cannot vouch for their handling of what arrives. Choose destinations appropriate for the sensitivity of branch revenue and worker names, and restrict who can read them.

A note on how ntfy works: any ntfy topic is readable by anyone who knows its name. For that reason we do not let you choose one. Topics are generated on our side with 128 bits of randomness, are never derived from your company name, and the platform refuses to publish to a topic that does not meet that standard. You can regenerate a topic at any time from Settings, which cuts the old one off immediately. Even so, an ntfy topic is a shared address rather than an account: treat the topic string as a secret, and use email or Telegram if you would rather have a channel tied to an identity.

Where you specify a webhook or channel endpoint, use an https:// address. The platform will call an http:// endpoint if you configure one, and traffic to it is not encrypted in transit. Operators running their own deployment can set OUTBOUND_REQUIRE_HTTPS=true to refuse plaintext endpoints outright.

We update this list when our providers change, and we give notice of material changes as described in the Privacy Policy and in Section 8.3 of our Data Processing Addendum, which also sets out your right to object to a new subprocessor.

Responsible disclosure

Found a vulnerability? Email security@pest-metrics.com. We read every report, respond quickly, and will not pursue legal action against good-faith security research.