Security

An email address, a name if you give one, your language and timezone, the time and browser (user agent) of your most recent sign-in, the identifier of your Google account if you sign in with Google, the list of companies you watch, the rules you wrote, any alert destinations you add — email addresses, Slack channels or webhook URLs — and the addresses of people you invite to your account. If an email we send bounces or is reported as spam, we also keep that address and the reason, so we stop mailing it. That is the whole inventory of customer data. The graph itself is compiled from public disclosures about companies and belongs to us, so a breach of the dataset would expose nothing about you that is not already published on the internet.

We never see a card number. Stripe hosts the card form, the invoices and the payment method itself; we only receive the plan and its status.

• TLS in transit. At rest, the database, stored files and backups sit on full-disk-encrypted volumes, and the credentials the service holds for you — webhook secrets, Slack tokens, partner-connection tokens — are additionally encrypted column by column.
• Application and data hosted by Hetzner in Germany, in the European Union.
• Access to production is held by the founder alone. Every infrastructure account requires multi-factor authentication, servers accept SSH keys only, the staff console requires a TOTP second factor, and everyone with access is bound by a written confidentiality obligation.
• Sign-in by magic link or "Sign in with Google," so there is no password to reuse, leak or phish out of you. A sign-in link works once, expires after 15 minutes, is stored only as a digest, and needs a click on a confirmation page — so an email scanner that opens it signs nobody in.
• Hetzner's automated server backups, kept for 7 days.
• Dependency and vulnerability scanning on every change, with known-exploited vulnerabilities patched as a priority interrupt.
• Staff actions logged in an append-only audit trail kept for 12 months.

The graph dataset sits behind an internal interface inside the application, and the code that serves your account reaches it only through that interface — an architecture test fails the build if anything reaches around it. That began as a decision about keeping the dataset portable, and it has a security consequence worth stating: a read of the dataset carries no customer identifier, because the interface has nowhere to put one. Watchlists, rules and inventories live on the application side and reference companies by identifier.

This product is self-serve only, and that is a permanent constraint rather than a stage. It rules out enterprise SSO and SAML, custom or granular roles and permissions, multi-client workspaces, custom contracts, and completed security questionnaires on request. Signing in is a magic link or "Sign in with Google" — a verified address either way, not an IdP integration. Teammates can be invited to an account (owner or member, with seats bounded by plan), but there is no SSO-driven provisioning and no custom permission model beyond those two roles.

We are not SOC 2 certified and we are not ISO 27001 certified. If your procurement process requires either, we are not yet a fit, and we would rather you learn that here than after three weeks of email.

What we offer instead is a short, specific description of a small system — this page, the DPA and our own subprocessor list — and the ability to cancel in one click if we stop being worth it.

Send security reports to security@nthparty.io. We acknowledge within two working days, we will tell you what we found and when it is fixed, and we will not threaten you for reporting in good faith. We have no bug bounty budget and we will not pretend otherwise.

Service status is published at status.nthparty.io, hosted by Better Stack, and planned maintenance is announced there before it happens. Disclosures are checked daily on every tier.