Как подготовить договор обработки данных для SaaS

Как подготовить договор обработки данных для SaaS

A weak data processing agreement can turn an ordinary vendor integration into a GDPR exposure. The immediate business risk is not only a regulatory fine of up to €20 million or 4% of worldwide annual turnover under Article 83 GDPR. It is also a stalled enterprise deal, a customer audit that cannot be passed, or a forced suspension of a data pipeline after a processor refuses to disclose its subcontractors.

For SaaS companies, e-commerce aggregators, scraping agencies, and data brokers, a DPA is not a boilerplate appendix. It defines who may access personal data, for what purpose, in which environment, for how long, and under whose instructions. If those answers are absent or contradict the actual technical architecture, signatures will not protect the business.

Как подготовить договор обработки данных

Start with the processing map, not with a downloaded template. A legally sound agreement follows the actual movement of data through the product: collection, enrichment, storage, customer support access, analytics, backups, and deletion. Engineering, security, product, and legal teams should validate this map together.

Under GDPR, the central distinction is between a controller and a processor. A controller determines the purposes and essential means of processing. A processor acts on documented instructions from the controller. A company may be a processor for one workflow and an independent controller for another. For example, a SaaS platform may process a client’s CRM records on the client’s behalf, while independently controlling account-manager contact data and its own billing records.

Mislabeling the roles creates a dangerous gap. Calling both parties “processors” does not remove their statutory obligations. Nor can a platform call itself a processor where it independently decides to reuse customer contact data for its own marketing, profiling, or dataset commercialization.

Зафиксируйте предмет и границы обработки

Article 28(3) GDPR requires a processor contract to describe the subject matter and duration of processing, its nature and purpose, categories of personal data, categories of data subjects, and the controller’s obligations and rights. These points should be specific enough for an auditor to understand the operation without reading product documentation.

“Processing user information to provide services” is usually too broad. A better description identifies the business function and technical scope. For a marketplace analytics provider, the purpose may be to host, normalize, and display customer-uploaded merchant and order data solely to provide contracted analytics. It should state whether the dataset contains names, business emails, phone numbers, delivery addresses, identifiers, IP addresses, payment-related metadata, or other personal information.

The same discipline matters in web scraping projects. A client may ask an agency to collect publicly available product listings, but a collection flow can capture seller names, business contact details, account IDs, or embedded personal information. The agreement must not present such data as anonymous merely because it was publicly accessible. Public availability does not automatically eliminate privacy, database-rights, contract, or copyright risk.

Роли сторон и законные инструкции

The contract must state that the processor acts only on documented instructions, unless applicable law requires otherwise. “Documented” should include a controlled set of channels: the agreement, service order, approved ticketing system, and written directions from authorized client representatives. This prevents informal requests through chats from silently expanding the processing purpose.

For a data aggregator, the instruction mechanism should address edge cases. Can the processor correct obvious errors in uploaded records? May it use a third-party enrichment provider? Can it retain logs to investigate fraud or uptime incidents? Each permitted activity needs a narrow legal and operational basis.

A useful DPA also protects the processor where an instruction is unlawful. It should require notice to the controller if an instruction appears to breach GDPR or other applicable data protection law, unless notification is prohibited by law. This is particularly relevant when a client instructs a scraping vendor to bypass access restrictions, collect login-protected data, or retain scraped personal data indefinitely.

Что включить в матрицу обязанностей

A short responsibility matrix often prevents more disputes than ten pages of generic legal wording. It should allocate at least the following operational decisions:

  • who provides notices to individuals and handles consent where consent is the legal basis;
  • who responds to access, deletion, objection, and portability requests;
  • who validates the legal basis for collection and disclosure to vendors;
  • who maintains records, performs impact assessments, and communicates with supervisory authorities;
  • who decides whether an incident requires notification to individuals or regulators.

The processor should assist the controller with data subject requests and compliance duties only to the extent required by Article 28 GDPR and reasonably possible given the service architecture. Assistance must be workable. A cloud-based SaaS provider cannot promise manual review of every historical backup within hours if the system does not support it. The agreement should set an escalation process, response timelines, and reasonable cost treatment for non-standard requests.

Безопасность должна совпадать с архитектурой

Article 32 GDPR requires security measures appropriate to the risk. A DPA should not simply state that the parties use “industry-standard security.” That phrase rarely answers a customer’s security questionnaire and offers little evidence after a breach.

Describe controls at a level that is accurate but does not disclose exploitable detail. Depending on the service, this may cover encryption in transit and at rest, role-based access control, multi-factor authentication for privileged accounts, logging, vulnerability management, backup segregation, environment separation, and staff confidentiality commitments.

The agreement should also distinguish customer responsibility from provider responsibility. If a customer administrator exports a database to an unmanaged laptop, the platform cannot realistically assume all resulting risk. Conversely, a provider cannot shift responsibility for a breach caused by excessive internal access rights or an exposed storage bucket.

For scraping agencies, IP blocks and API throttling are not only technical inconveniences. They may indicate that the collection method exceeds permitted access or violates a platform’s restrictions. The DPA should not be used to normalize unlawful instructions. A broader review may be needed: the target site’s terms, access controls, applicable database protections, copyright position, and the source of personal data.

Уведомление об утечке и доказательства

A processor must notify the controller of a personal data breach without undue delay after becoming aware of it under Article 28(3)(f) GDPR. The contract should define a practical incident channel available outside standard business hours, identify decision-makers, and require phased information sharing.

The first notice may contain only confirmed facts: the affected system, known data categories, containment steps, and the current investigation status. Later updates can refine the number of affected individuals and the likely consequences. Requiring a complete forensic report before any notification is counterproductive because controllers may need to assess the GDPR’s 72-hour regulatory notification deadline.

The agreement should preserve evidence and coordinate communications. It must not allow a processor to notify affected customers or authorities in the controller’s name without authorization, except where law independently requires it.

Субпроцессоры и международная передача

Most SaaS providers rely on hosting, observability, email delivery, customer support, and security vendors. If the DPA says there are no subprocessors while the production stack uses several, it is inaccurate on day one.

Use either specific prior authorization or general written authorization with a clear objection process. The processor remains responsible for its subprocessors’ compliance with equivalent data protection obligations. Maintain a current list that identifies the vendor, service function, and processing location. The controller’s objection right should be meaningful, but it should not give a customer an unlimited veto over core infrastructure without a commercial solution. The contract can provide alternatives, such as a reasonable transition period, service modification, or termination of the affected service.

International transfers require separate attention. Storage in the European Economic Area does not automatically mean that no transfer occurs. Remote support access, group-company administration, and certain vendor arrangements may trigger Chapter V GDPR analysis. Where a transfer mechanism is needed, the parties should identify it and ensure that contractual wording aligns with the real transfer flow. Standard Contractual Clauses may be relevant, but they are not a substitute for assessing supplementary measures and the specific access risk.

For U.S.-facing operations, a DPA should also be consistent with CCPA and CPRA contractual restrictions when the parties act as a business, service provider, contractor, or third party. Do not copy GDPR terminology into a California clause without checking the actual role and permitted use of personal information. The key issue is whether the recipient is prohibited from selling, sharing, retaining, using, or disclosing personal information outside the permitted business purpose.

Удаление, возврат и проверка соблюдения

At the end of services, Article 28 GDPR generally requires deletion or return of personal data, unless law requires retention. “Delete upon termination” is too imprecise for distributed systems. Specify the treatment of active production data, backup cycles, audit logs, legal holds, and pseudonymized operational records.

Audit rights also need balance. Enterprise clients require evidence, but unlimited on-site audits can expose other customers and disrupt a multi-tenant platform. A proportionate model may include current independent assurance reports, written questionnaires, an annual audit limit, reasonable advance notice, confidentiality safeguards, and on-site access only where documents do not resolve a material concern.

A DPA should be signed only after the technical and commercial teams confirm that its commitments can be performed. Promising universal deletion, immediate incident reporting, or unrestricted audit access may win procurement approval briefly, but it creates contractual breach risk from the first production deployment.

Our data lawyers prepare and negotiate processing agreements that match data flows, vendor stacks, scraping operations, and cross-border expansion plans. We can audit an existing DPA, align it with GDPR, CCPA, and applicable local rules, and turn customer due diligence into a controlled legal process. Contact Data Lawyer Agency to discuss the agreement before a client audit, vendor rollout, or data incident forces the issue.