Privacy Policy

BleedWatch SASU is the intended controller for account administration, billing, marketing, website analytics, security logging, and support interactions. For customer scan data processed inside the platform, BleedWatch may act as a processor under the Data Processing Addendum.

Customers decide which assets are submitted, which integrations are connected, which users are invited, and which findings are routed to external tools. Those customer decisions may determine whether BleedWatch is acting as controller, processor, or independent security provider for a specific processing activity.

The production policy should identify the legal entity, registration details, postal address, privacy contact, and any data protection officer or representative if one is appointed. It should also explain how privacy requests are authenticated.

Questions about privacy handling should be sent to [email protected] until a dedicated privacy inbox or data protection officer contact is published.

BleedWatch may process account data such as name, email address, organization, role, authentication events, plan, billing status, support history, and product preferences. Payment card details should remain with Stripe or another payment processor and not be stored directly by BleedWatch.

The service may process asset data such as domains, package names, repository identifiers, registry references, DNS records, certificate metadata, scan configuration, integration identifiers, tickets, notification destinations, and module-specific settings.

Findings may include security evidence, risk labels, truncated secrets, hashes, redacted previews, remediation notes, timestamps, affected systems, and workflow routing metadata. The production policy should be explicit about redaction, preview length, and secret handling.

Website and product telemetry may include device data, IP address, browser, approximate location, session events, error logs, performance metrics, consent choices, and security events. Analytics should remain privacy-conscious and configurable where required.

Account creation, authentication, service delivery, support, billing, and contractual notifications are generally processed to perform a contract or take steps before entering a contract. Enterprise procurement and order-form activity may also rely on contract necessity.

Security monitoring, abuse prevention, fraud detection, service diagnostics, product reliability, and limited internal analytics may rely on legitimate interests where those interests are not overridden by individual rights and freedoms.

Marketing emails, non-essential cookies, and some optional analytics may require consent depending on location and channel. The production policy should describe how consent is collected, recorded, withdrawn, and respected across devices.

Product communications about security, billing, incident response, support, and service changes may be treated differently from promotional marketing because customers need those notices to operate the service safely.

Legal compliance, accounting, sanctions screening, law-enforcement response, and regulatory obligations may require processing under legal obligation. Counsel should finalize this section by jurisdiction before launch.

Account records should be retained while the account is active and for a reasonable period afterward for billing, security, dispute resolution, and audit purposes. The exact windows should be finalized before launch and aligned with subscription, tax, and support obligations.

Scan findings and evidence may need separate retention windows by tier. Community accounts may receive shorter retention, while enterprise customers may negotiate longer retention or deletion obligations in an order form or DPA.

Security logs, audit logs, and abuse-prevention records may be retained longer where necessary to protect the service, investigate incidents, demonstrate compliance, or defend legal claims. Logs should minimize sensitive content where operationally possible.

Deletion requests should be handled according to verified identity, role authority, legal holds, product dependencies, and processor obligations. The production implementation should document export and deletion workflows in the app and docs.

Retention defaults should be visible enough for buyers to compare Community, paid self-serve, and enterprise expectations without opening a support ticket.

Depending on applicable law, individuals may have rights to access, correct, delete, restrict, object to, or port their personal data. They may also have the right to withdraw consent where processing is based on consent.

BleedWatch should respond to verified requests within the time required by applicable law. If the request relates to customer-controlled scan data, BleedWatch may direct the requester to the customer or assist the customer as processor under the DPA.

Requests may be limited where BleedWatch must preserve security logs, comply with legal obligations, protect third-party rights, maintain confidential information, or prevent abuse. Any refusal should be explained in a clear and lawful manner.

Privacy requests should be sent to [email protected] until a dedicated privacy workflow is published. The production policy should include the exact request format and identity-verification approach.

BleedWatch may use subprocessors for hosting, infrastructure, email delivery, payment processing, analytics, support tooling, logging, and customer communications. The active list should remain available at /trust/sub-processors.

Subprocessors should be reviewed for security, privacy, contractual safeguards, data location, and operational need before use. Enterprise customers may receive notice of material changes according to the DPA or order form.

Where BleedWatch acts as processor, subprocessors should be bound by written terms that protect customer personal data at least as strongly as the DPA requires. The production DPA should describe objection rights and replacement mechanics.

This placeholder does not name a final list. Founder and counsel should reconcile it with actual infrastructure before launch.

BleedWatch intends to keep core customer data in the European Union where feasible, but some subprocessors, support workflows, or integrations may involve transfers outside the European Economic Area.

International transfers should rely on appropriate safeguards such as adequacy decisions, Standard Contractual Clauses, supplementary measures, or another lawful transfer mechanism. Counsel should finalize the transfer language after subprocessor review.

Customers may connect third-party integrations that transfer findings or notifications to tools they control. The customer is responsible for assessing those destination tools and configuring them according to their own policies.

The production policy should explain how transfer safeguards can be requested, including any enterprise security package, DPA attachment, or compliance documentation.

BleedWatch may use essential cookies or similar technologies for authentication, session security, load balancing, fraud prevention, and service reliability. Essential cookies are required for the site and application to work.

For website analytics, BleedWatch operates Umami self-hosted on its own EU infrastructure (analytics.bleedwatch.com). Umami runs cookieless: it sets no persistent cookies, collects no personal identifiers, and does not enable cross-site or cross-device tracking. Aggregate page views and custom events (CTA clicks, form submissions) are stored on BleedWatch infrastructure only — there is no third-party analytics processor and no GDPR-style consent banner is required for this baseline analytics.

If marketing tools that DO set cookies are introduced later (advertising pixels, third-party heatmaps, etc.), the site will surface a consent banner with category-level controls and update the public sub-processor list at /trust/sub-processors before activation.

The production cookie inventory should list cookie names, providers, purposes, durations, and opt-out controls. This anchor intentionally remains #cookies so product, footer, and consent-related links stay stable.

Browser-level controls may block or delete cookies, but doing so can affect authentication and service behavior. BleedWatch will not implement dark patterns in any future consent UX.

BleedWatch may update this policy to reflect product changes, legal requirements, subprocessor changes, security improvements, or operational lessons. Material changes should be communicated through appropriate product, email, or website notices.

The last-updated date should change whenever the policy changes. Archived copies should be retained where needed for enterprise review, regulatory response, or customer dispute resolution.

If a change materially affects customer-controlled data processing, the DPA or order form may require advance notice or objection rights. Counsel should align this policy with those contractual mechanics.

Continued use of the service after an update may indicate acceptance where permitted by law. Consent-based processing should still respect separate consent requirements.