Built for the team your counsel asks about.

Every customer's data lives in its own tenant scope. Cross-tenant access requires bypassing every one of the following layers, and at least the first two are enforced in code on every read and write.

• Google and team accounts. Use your Google account to sign in, or use the email and password for a team account issued by Brand Protector. Google sign-in requires a verified email address.
• Per-tenant membership checks on every read and write. The tenant id comes from the URL path; it is then passed to a server-side membership helper before any DB call.
• JWT sessions, max 8h, revocable per user. Member removal, tenant pause, self-service “sign out all sessions”, and platform-admin force-revoke all bump a per-user timestamp that invalidates issued tokens on their next request.
• Step-up reauth for privileged platform-admin actions. Suspending a tenant or impersonating a member requires a fresh Google sign-in plus an HMAC-signed elevation cookie with a 5-minute TTL.
• Platform-admin sign-in hardening. The platform console is restricted to accounts we explicitly mark as platform admins, and every privileged action additionally requires a fresh Google sign-in plus the short-lived elevation cookie above. We record whether each platform-admin sign-in demonstrated multi-factor authentication (the OIDC amr claim), and the enforcement gate that turns that signal into a hard block is built and staged but not currently enabled, so we do not claim it as an active control.

The audit log is protected in layers:

• A scoped Firestore Security Rules block denies every operation against the per-tenant audit subcollection from any client-side path.
• A least-privilege scanner service-account role denies audit deletion to the workload that produces audit entries.
• Every audit row is exported nightly to a separate Google Cloud Storage archive and kept for seven years.
• The audit log is customer-visible inside the workspace with date-range filtering and CSV export at any time.

• Article 15 (right of access). Owners and admins can request a complete workspace data export from settings. The export is generated asynchronously as a single ZIP archive (one JSONL file per subcollection: detections, takedowns, cases, audit log, members, configuration and onboarding state, plus webhook endpoints as metadata only: signing secrets stripped). A signed download link is emailed and valid for 7 days; the archive is purged from our storage after 30 days.
• Article 17 (right to erasure). Owners can pause a workspace from settings. When a subscription is canceled, the workspace's records and stored credentials are deleted 30 days later, and earlier deletion is available on request. For individual data subjects, audit-row pseudonymization is an operator-run request to privacy@brandprotector.io rather than a self-serve action: member removal and Leave workspace deliberately leave the audit trail intact. On request the individual's email is replaced with a stable per-tenant pseudonym and the trail's integrity is preserved.
• Articles 16, 18, 20, 21. Rectification and portability self-serve from the settings UI; restriction and objection requests are handled by privacy@brandprotector.io.

• Uptime checks on the app's health and readiness endpoints, with alerts to our team.
• Rate limiting on sign-in, inbound webhooks and data exports.
• Outbound webhooks are HMAC-signed following the Standard Webhooks scheme, and customer-configured destination URLs are validated against SSRF (no private-network or metadata-endpoint targets) before any request leaves the platform.
• Per-request correlation IDs surfaced in error responses and customer support.
• Internal platform-admin scanner-health dashboard so issues in third-party scrapers or AI providers are caught before they reach customers.
• Data encrypted at rest and in transit (Google-managed encryption on Cloud Firestore and Cloud Storage); tenant data restore on request during the 30-day soft-delete window after cancellation.

The full list of sub-processors, with locations, is kept current in the DPA; below is the live snapshot.

• GDPR Article 28 processor obligations are in our DPA, available on request signed.
• Standard Contractual Clauses (Module 2 controller-to-processor) cover EU-to-US transfers; UK IDTA covers UK transfers.
• CCPA/CPRA: we do not sell or share personal information.