Data Processing Addendum

Customer Personal Data means personal data that BleedWatch processes on behalf of a customer through the service, including account-related scan configuration, integration metadata, findings, evidence, and support materials where they identify or relate to an individual.

Processing, controller, processor, subprocessor, data subject, personal data, and supervisory authority should have the meanings given by applicable data protection law. Counsel should confirm the final statutory references before launch.

Security Incident means a confirmed breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data processed by BleedWatch.

This DPA placeholder is intended to attach to the Terms of Service, an order form, or a master services agreement. If there is a conflict, the signed enterprise agreement should state which document controls.

BleedWatch processes Customer Personal Data to provide continuous external attack surface monitoring, package and repository analysis, finding correlation, notification routing, reporting, support, security, and service administration.

The duration of processing should follow the customer's subscription term, trial term, order form, and post-termination retention windows. Some audit, billing, and security records may be retained longer where legally or operationally required.

The categories of data may include user identifiers, organization details, submitted assets, scan metadata, evidence previews, integration destinations, tickets, support communications, and security logs. Sensitive data should be redacted, hashed, truncated, or minimized where the product allows.

The categories of data subjects may include customer employees, contractors, authorized users, administrators, support contacts, and individuals incidentally referenced in customer-controlled assets or findings.

The customer is the controller or processor, as applicable, for Customer Personal Data submitted to the service. The customer is responsible for lawful instructions, authorized scope, notices, consents, internal approvals, and the accuracy of submitted assets.

BleedWatch acts as processor when processing Customer Personal Data on documented customer instructions to provide the service. BleedWatch may act as independent controller for account administration, billing, abuse prevention, service security, and legal compliance.

BleedWatch should process Customer Personal Data only as instructed by the customer, unless required by law. If BleedWatch believes an instruction is unlawful or unsafe, it should notify the customer where legally permitted.

Both parties should maintain appropriate technical and organizational measures, train personnel with access to Customer Personal Data, and cooperate in good faith on compliance obligations that apply to the service.

The active subprocessor list should be maintained at /trust/sub-processors and should identify provider name, purpose, location, and material processing role. This DPA should link to that page as the operational source of truth.

BleedWatch should conduct reasonable diligence before appointing subprocessors and require written terms that protect Customer Personal Data. Those terms should include confidentiality, security, breach notice, assistance, deletion, and onward-transfer obligations.

Enterprise customers may receive notice of new or replacement subprocessors and a reasonable objection process, depending on the order form. The production DPA should define notice timing, objection standards, and fallback remedies.

Customers remain responsible for third-party integrations they connect directly, such as Slack, Jira, Linear, ServiceNow, GitHub, SIEM, or webhook destinations, unless those tools are separately listed as BleedWatch subprocessors.

BleedWatch should maintain technical and organizational measures appropriate to the risk, including access control, least privilege, encryption in transit, encryption at rest where applicable, vulnerability management, logging, monitoring, and incident response.

Product-specific measures may include redaction of secret previews, tenant isolation, scoped integrations, audit trails, active-scan allowlists, KMS proxy controls, digest-pinned tool images, argv sanitization, and circuit breakers for SaintScan execution.

Personnel with access to Customer Personal Data should be bound by confidentiality obligations and should receive security guidance appropriate to their role. Production policy should define onboarding, offboarding, and access-review cadence.

Security measures may evolve as the service changes. BleedWatch should not materially decrease the overall security of the service during a subscription term without a commercially reasonable reason and notice where required.

If BleedWatch receives a request from a data subject relating to Customer Personal Data, it should notify the customer where legally permitted and should not respond on the customer's behalf unless instructed or legally required.

BleedWatch should provide reasonable assistance for access, correction, deletion, restriction, objection, portability, or consent-withdrawal requests that the customer cannot fulfill independently through the product.

Assistance may depend on verified authority, technical feasibility, identity validation, legal holds, security obligations, and the nature of the data. Production workflows should explain whether customers can export or delete records directly.

Requests involving account administration or billing data controlled by BleedWatch may be handled directly by BleedWatch under the Privacy Policy rather than this processor workflow.

BleedWatch should make reasonable compliance information available to customers, such as security summaries, architecture notes, subprocessor lists, and answers to security questionnaires. Enterprise security packages may include additional documentation under NDA.

On-site audits should be exceptional, scoped, pre-scheduled, confidentiality-protected, and limited to what is necessary to verify compliance with the DPA. The production DPA should define notice periods, frequency limits, and cost allocation.

Independent attestations, penetration-test summaries, architecture reviews, and policy evidence may satisfy audit requests where they provide equivalent assurance. Counsel should align this with SOC 2, ISO 27001, NIS2, and procurement expectations.

Audit rights should not require BleedWatch to disclose other customers' data, trade secrets, detection logic, employee personal data, or information that would compromise service security.

This DPA should remain in effect while BleedWatch processes Customer Personal Data on behalf of the customer. It should terminate when processing ends, except for provisions that must survive by nature or law.

After termination, BleedWatch should delete or return Customer Personal Data according to the product, order form, DPA, and legal obligations. Backup and audit-log deletion may follow normal retention cycles where immediate deletion is impractical.

Customers should request exports before account closure where they need reports, evidence, or audit material. BleedWatch should document the availability and limits of export tools before production launch.

Deletion may be delayed where retention is required for security, fraud prevention, legal defense, tax, accounting, regulatory compliance, or unresolved disputes.

Liability for data protection obligations should be governed by the Terms of Service, order form, master services agreement, or other signed commercial agreement. Counsel should ensure the liability cap and carve-outs are internally consistent.

The DPA should clarify how regulatory fines, third-party claims, security incidents, confidentiality breaches, unpaid fees, gross negligence, willful misconduct, and indemnity obligations are handled.

Nothing in this placeholder should be treated as a final allocation of risk. It exists to make the page reviewable while founder and counsel finalize contract language.

Customers should not rely on this placeholder for procurement approval until a signed or counsel-reviewed version is published.

This placeholder DPA is intended to follow the same governing law and venue as the Terms of Service unless the signed enterprise agreement states otherwise.

Where EU data protection law requires a different mandatory forum, supervisory authority process, or statutory term, that requirement should control. Counsel should finalize the hierarchy before launch.

If Standard Contractual Clauses or other transfer mechanisms are needed, they should be attached as a separate module or exhibit and incorporated clearly.

Questions about this DPA, enterprise contracts, subprocessors, or security evidence should be sent to [email protected].