What must a SaaS company have before an enterprise customer signs under GDPR?
The GDPR requires no certificate before an enterprise customer signs, but a SaaS vendor acting as processor must have a binding written contract that meets Article 28(3), and it must be able to show evidence for each duty that contract names. Procurement and privacy teams usually check that contract first, then test it against a security questionnaire: which processing is covered, which documented instructions apply, how staff confidentiality is kept, how sub-processors are authorised and listed, how breaches are reported, how the customer is helped with rights requests, what happens to data at the end, and how audits are supported. Electronic form is acceptable, but the terms must be specific enough to show how each requirement is met, since general restatements of the regulation carry little weight with assessors.
The work and cost depend on the data types you process, how many sub-processors sit in the chain, where data is hosted and who can access it, and how many customers you serve. Start by listing every processing activity you run for customers and mapping it to the evidence you hold: a current sub-processor list, a written description of your technical and organisational security measures (the Commission's controller-processor clauses in Decision (EU) 2021/915 expect this), breach procedures with customer notice timings, and a deletion or return process you have actually tested. Confirm with your counsel which terms your standard agreement already covers and which need negotiation. Your organisation owns these controls. An implementation partner can prepare systems, documentation and evidence, but only an independent auditor or certification body issues any report, and no such report is required by the GDPR itself.
Which Article 28 terms customers will look for in the processing agreement
The processing agreement is where a SaaS vendor turns the Article 28 duties into specific commitments customers can test. Each term below should say how the requirement is met, not repeat the regulation.
Confirm the agreement is binding and in writing
Start by checking that the processing terms are a binding contract or legal act between your company and each customer, in writing or in electronic form. Your legal team owns the wording, and the signed version or click-through acceptance record is the evidence customers will ask for. Keep a version history so you can show which terms applied to each customer at each point in time.
Define documented instructions and transfer limits
Specify that you process personal data only on the customer's documented instructions, including for any transfer outside the EEA. Name the instruction channel (the service configuration, the order form or a written request) and the transfer locations or mechanisms that apply. The output is a clause and an annex a customer can compare with its own processing records.
Set staff confidentiality and security measures
Commit that everyone authorized to process the data is bound by confidentiality, then attach a description of your technical and organizational security measures. Customers expect this annex to be specific: access control, encryption, logging, backup and restore, and any relevant certifications, each tied to the systems in scope. Your security lead should review it against the actual environment before it is sent.
Write sub-processor conditions into the contract
Describe how you engage sub-processors, whether under specific or general written authorization, how changes are notified and how customers can object. Confirm that each sub-processor is bound by the same data protection obligations. The output is a clause plus a current sub-processor list that matches what your engineering team has actually deployed.
Commit to help with rights requests and high-risk duties
State how you will assist the customer with data subject requests and with its duties on security, breach notification, impact assessments and prior consultation. Name the response channel and the information you will supply, such as logs, exports or configuration details. Support leads should confirm they can meet the commitment with the tools and staff available.
Specify deletion or return at the end of service
Set out whether data is returned, deleted or both when the contract ends, and how the customer chooses. Describe how deletion reaches backups, replicas and sub-processors, and what written confirmation you provide. Engineering should be able to show the deletion procedure working on a test tenant before the commitment goes into the contract.
Define information and audit rights
Set out what information you will provide to demonstrate compliance and how customers can audit or inspect, including by an independent auditor. Many vendors offer a standard evidence pack first and on-site or remote inspections only where the evidence falls short. Confirm the procedure, notice period and cost arrangements with your legal and compliance leads.
What evidence answers the questions customers actually ask
Enterprise customers rarely ask for a GDPR certificate, because none is required. They ask for documents that show how the processor handles their data, who else touches it, and how it responds when something goes wrong. The cards below cover the six items that most often answer those questions, and each one should exist before a sales review starts.
Sub-processor list and change process
Maintain a current list naming every sub-processor, its location, the processing it performs and the transfer mechanism where data leaves the EEA. Under general authorisation, the change process must notify customers before a new sub-processor is added so they can object, and the same data protection obligations must be imposed on that sub-processor. Confirm with each customer which authorisation model their contract uses, and check that your notice period actually allows an objection before the change takes effect.
Technical and organisational security description
Write a description of the security measures that apply to the customer's data, covering access control, encryption, logging, backup and restore, and staff training. Annex III of Decision (EU) 2021/915 asks for this description, including any relevant certifications you hold. Keep it specific to the service, so it reads as a description of your controls rather than a restatement of Article 32. Name each certification and its scope, and say plainly when you hold none.
Article 30(2) processing record
A processor must keep a record for each controller that lists the categories of processing performed, any transfers to third countries and, where possible, a general description of security measures. Customers will ask for this when they map their own records. Keep it current when you add features, regions or sub-processors, and make sure the entries for each customer match the processing they have actually contracted for.
Breach notification procedure
Document how you detect a personal data breach, who decides it is reportable to the customer, the deadline for notice, and what the first notice contains. Article 33(2) requires notice without undue delay, and the EDPB's guidance supports phased notification with further details as the investigation proceeds. Ask customers whether their contract requires early notice to help them meet the 72-hour deadline, and test the procedure with a tabletop exercise.
Rights request runbook
Assist customers with access, erasure, rectification and other rights requests by writing a runbook that covers intake, routing to the customer, the tools that locate data in each system, and the handling of backups and logs. Define who can export or delete a record and how that action is logged. Confirm which requests you handle directly and which require a customer instruction, because the answer changes the contract and the staffing.
Deletion and return procedure
At the end of the service, the contract must require you to delete or return all personal data, at the customer's choice, and to delete existing copies unless law requires storage. Document the steps, the timeline agreed in the contract, how deletion extends to backups and sub-processors, and the certificate or log you will issue. Customers increasingly ask to see a sample of this output before they sign, so prepare one from a test tenant.
How sub-processors and transfers change the contract
Your contract with each customer has to say how you engage sub-processors, and the choice between specific written authorisation and general written authorisation under Article 28(2) decides what your customers can do when you change a supplier. Under specific authorisation, the customer approves each named sub-processor before you use it. Under general authorisation, which most SaaS contracts use, you may add or replace sub-processors, but you must tell the customer about each change in advance so it has the chance to object. Decide which model you offer, write the notice period and objection route into the agreement, and make sure your team can produce the current list on request. The clause should also say what happens if the customer objects and you cannot drop the supplier.
Whichever model you choose, Article 28(4) requires you to impose the same data protection obligations on each sub-processor by contract, so the security, confidentiality, breach notice and assistance duties do not stop at your own boundary. For each sub-processor, keep a copy or summary of the flow-down terms and check that the breach notice period you promise customers is one your suppliers can meet. If a sub-processor sits outside the EEA, or gives staff outside the EEA remote access to personal data, that is a transfer, and the customer's contract must cover it. Confirm which transfer mechanism applies to each location, whether that is an adequacy decision such as the EU-US Data Privacy Framework under Commission Implementing Decision (EU) 2023/1795, or the standard contractual clauses in Commission Implementing Decision (EU) 2021/914. Check the current status of any adequacy decision with the regulator or your legal adviser before you rely on it, because the supplied facts do not confirm its status beyond the decision's adoption.
How breach notice to customers works under Article 33(2)
The sequence gives the controller the facts it needs to decide on notification to its supervisory authority and to affected individuals, within the 72-hour window that starts when the controller becomes aware of the breach.
Detect and confirm the incident
The processor's security or operations team confirms that a personal data breach has occurred, meaning a security incident has led to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. Detection usually comes from monitoring alerts, a customer report, a sub-processor notice or a researcher disclosure. The record of the first confirmed facts, with the time they were established, is the output of this step and starts the processor's own clock for notice.
Contain the breach and preserve evidence
Engineers isolate affected systems, revoke compromised credentials and stop the exposure, while the incident lead keeps logs, images and access records intact for later analysis. Where a sub-processor hosts part of the affected service, the processor asks it to do the same. The output is a containment note that states what was done, by whom and when, so it can be included in the information given to the customer.
Identify the affected customers and data
The processor maps the incident to each controller whose personal data was involved, using tenant identifiers, record counts and data categories from its processing records. Article 30(2) requires processors to keep records of the processing they carry out for each controller, and those records make this mapping possible. The output is a list of affected controllers with the categories of data and individuals known so far. Confirm that your records can be queried this way before an incident occurs.
Notify each affected controller without undue delay
The processor sends the initial notice to each affected controller's named contact, as the contract defines it. Article 33(2) requires the processor to notify without undue delay, and the EDPB's Guidelines 9/2022 on personal data breach notification (version 2.0) explain that the processor does not need full facts before it gives this first notice. The output is a dated notice showing the time of awareness, what is known, and the next update date. Contracts can set an early notice requirement so the controller keeps time for its own 72-hour deadline.
Provide further information in phases
As the investigation proceeds, the processor sends updates covering the cause, the scope, the number of records and individuals, the likely consequences and the measures taken. The EDPB guidance recommends phased notice so that controllers receive accurate information without waiting for a complete report. The output is a numbered series of updates, each stating what changed since the last one. Article 28(3)(f) requires the processor to assist the controller with Articles 32 to 36, so the controller can rely on these updates for its own report.
Support the controller's notification and communication decisions
The processor supplies the technical facts the controller needs to notify its supervisory authority under Article 33 and, where required, to inform affected individuals under Article 34. The controller decides on notification and bears that responsibility, so the processor does not notify regulators or individuals on its own initiative unless the contract or law requires it. The output is a written package of facts, timelines and remediation evidence, delivered on request.
Close the incident and document the lessons
The processor completes its root cause analysis, records the breach in its internal register, and confirms to each controller that the remediation is finished. Recent regulator decisions show that supervisors examine whether security measures were adequate before the incident. The Swedish DPA fined Miljödata i Karlskrona approximately EUR 160 000 on 8 October 2026 for insufficient technical measures, and the CNIL fined Hôpital Privé de la Loire EUR 500 000 on 9 September 2026 in a health data breach case. These decisions are illustrations of the security expectations that a closing report should address. The output is a closure report with corrective actions and their owners.
Who owns each processor duty
The engineering and security team owns the technical substance of the processor's Article 32 measures and the operational proof behind them. Article 28(3) requires the processor to take those measures, support Articles 32 to 36, and provide information for audits, and the Annex III description in the Commission's controller-processor clauses expects a concrete account of technical and organizational measures. The team decides what the controls are, runs them, and produces the records a customer will ask for.
- Security measures description: Write the technical and organizational measures in terms of real systems, such as encryption, access control with MFA, logging, backup and restore, and vulnerability management, and keep the description current.
- Breach detection and notice inputs: Maintain detection and triage so the processor can notify the controller without undue delay under Article 33(2), and supply the facts in phases.
- Sub-processor technical configuration: Know which hosting, support and tooling providers touch customer data and what access each one holds.
- Deletion and return mechanics: Build tested procedures to return or delete customer data and to remove it from backups within a documented window.
- Audit evidence: Keep configuration exports, access reviews and test results that answer most customer questionnaires.
Before signing, ask the team to confirm each measure against the running environment, not only against the design document.
Legal and privacy staff own the contract, the role analysis and the commitments the company makes to customers. The Article 28(3) agreement must be binding, in writing or electronic form, and must specify how the GDPR requirements are met rather than restate them, as the EDPB's Guidelines 07/2020 explain. This team also negotiates the sub-processor notice and objection mechanism and decides how the company responds to customer audit requests under Article 28(3)(h).
- Processor agreement: Own the Article 28(3) terms covering documented instructions, staff confidentiality, assistance, deletion or return, and audit rights.
- Sub-processor terms: Set the authorisation model, notice periods and objection process, and make sure the same obligations flow down to each sub-processor.
- Role determination: Confirm when the company acts as a processor and when it becomes a controller under Article 28(10), since a company that sets its own purposes takes on controller duties.
- Audit response policy: Define who answers audit requests, what the company will disclose, and how confidentiality is protected.
- Liability and cooperation terms: Review liability exposure under Article 82(2) for breaches of processor duties or unlawful instructions.
Legal review should confirm that every commitment in the contract has a named owner on the engineering side.
An implementation partner such as DeployOpen prepares systems, runbooks and evidence inside the client's own infrastructure. It does not own the company's processor obligations, does not sign the Article 28 agreement on the company's behalf, and does not issue reports or certificates. Its work supports the engineering and legal owners by making the controls exist, repeatable and documented. Engagements are typically fixed-scope, with scope and deliverables agreed in writing before work starts.
- Environment preparation: Set up and harden self-hosted open-source platforms, access controls, logging and backup routines in the company's cloud accounts or data centers.
- Runbooks and procedures: Write deletion, restore, breach triage and access review runbooks that the internal team can run and test.
- Evidence packs: Assemble configuration exports, test records and control documentation that map to the customer's questions.
- Security testing: Run application, API and infrastructure testing so that the company can show findings and remediation.
- Ongoing support: Offer retainers for upgrades, backup testing and continuing evidence collection where the company wants them.
Confirm in writing which deliverables the partner owns and which remain with the company, because the company stays responsible for compliance.
Two outside parties test the processor, and neither is the implementation partner. An independent auditor or certification body issues any report or certificate. A customer, or an auditor the customer appoints, carries out an audit under Article 28(3)(h), which requires the processor to allow and contribute to audits and inspections. Certification under Article 42 is voluntary, is issued for at most three years, and does not reduce the processor's responsibility. The GDPR itself requires no audit or certificate.
- Customer audits: The customer or its appointed auditor decides the audit scope; the processor provides information, evidence and access as the contract allows.
- Certification bodies: Accredited bodies or supervisory authorities issue Article 42 certifications, which can help show sufficient guarantees under Article 28(5).
- Independent assessments: Where the company seeks a third-party report, it selects and pays an independent assessor and owns the resulting report.
- Scope of certification: Check exactly which services, locations and sub-processors a certificate covers before relying on it.
- Cost drivers: Audit frequency, scope, number of customers and the depth of on-site or remote access all change the effort.
Ask any vendor claiming a certificate for the issuing body, the scope statement and the validity dates.
What usually delays enterprise deals and how to avoid it
Enterprise customers review a SaaS processor's paperwork and technical claims before they sign. The gaps below appear again and again in those reviews, and each one can stall a deal long after the product has passed technical evaluation. Each card names the check a customer will run and the step that closes the gap.
A generic processing agreement
A data processing agreement that only restates the GDPR gives a customer nothing to verify. Article 28(3) requires specific terms on instructions, confidentiality, security, assistance and audits, and EDPB Guidelines 07/2020 expect the contract to say how those requirements will be met. Avoid this by mapping each Article 28(3) element to a named clause, a described process and an owner, and by attaching the security description the contract refers to.
An out-of-date sub-processor list
Customers need to name every sub-processor at any time, and under general authorisation they must receive notice of changes early enough to object. A list that lags behind the actual hosting, support and tooling stack triggers questions about undisclosed transfers. Avoid this by tying the list to your vendor onboarding process, publishing a change notice with the objection window you agreed, and checking each new sub-processor for transfers outside the EEA.
Undocumented security measures
Customers ask for a description of your technical and organisational measures, and the Commission's controller-processor clauses ask for any relevant certifications. When the answer is a sales slide or a verbal assurance, security questionnaires stall and the deal waits for an engineer. Avoid this by keeping one current security description that covers access control, encryption, logging, backup and vulnerability handling, with each statement traceable to a configuration or policy an assessor can inspect.
No tested deletion or return process
At the end of the service, Article 28(3)(g) requires the processor to delete or return personal data at the controller's choice. Customers will ask how long data persists in backups and logs and whether deletion has ever been performed end to end. Avoid this by writing the deletion and return procedure with defined retention for backups, running a test on a non-production tenant, and keeping the record of the result.
Processor actions that become controller decisions
A processor that decides the purposes or essential means of processing is treated as a controller for that processing under Article 28(10), and Article 82(2) makes it liable for acting outside instructions. Product teams can drift into this by reusing customer data for their own analytics or model training. Avoid this by writing down the instructions you act on, reviewing new features against them, and escalating any proposed secondary use to legal review before it ships.
Questions SaaS buyers ask before they sign
Do we need a GDPR certificate to sell to EU customers?
No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce your responsibility as a processor for compliance. What customers actually check is a written processing agreement that meets Article 28(3), a description of your technical and organisational security measures, a sub-processor list, and a clear breach notice commitment. A certificate can support those claims, but it is not a substitute for any of them.
Does a SOC 2 or ISO 27001 report satisfy Article 28?
No. A SOC 2 report or ISO/IEC 27001 certificate can support a processor's sufficient guarantees under Article 28(1), and it can help answer a customer's security questionnaire or audit request. It does not replace the contract. Article 28(3) requires a binding, written agreement that sets out the subject matter, duration, nature and purpose of processing, the data types and data subjects, and the processor's specific obligations. EDPB Guidelines 07/2020 say the agreement should not merely restate the GDPR but specify how requirements will be met. Expect customers to ask for both the contract and the evidence behind it.
What does the work need from our SaaS team?
The work needs named owners in engineering, security, legal and customer support, because most processor duties depend on system facts only your team holds. Typically this includes:
- A written list of what personal data each customer sends, where it is stored and which systems touch it
- Your current sub-processor list, with locations and transfer mechanisms
- Records of how you handle instructions, deletion, backups and access to customer data by staff
- Breach detection and escalation paths, with named contacts for customers
- Evidence of existing security controls, such as access reviews, logging and encryption settings
The organisation remains the one that owns these controls. An implementation partner can prepare systems and evidence, but it does not decide your processing or issue reports.
How long does this take, and what sets the timeline?
No timeline figure has been confirmed for this work, so ask for one in a written, fixed-scope quote rather than relying on a general estimate. The timeline depends on how many products and customer contracts are in scope, how much of your documentation already exists, how many sub-processors must be reviewed, and whether security measures need changes before they can be evidenced. Regulators also keep moving: Regulation (EU) 2025/2518 applies from 2 April 2027 to cross-border enforcement procedures, and the Omnibus proposals remain under negotiation, so confirm that the scope accounts for current text. Ask for milestones and the deliverables attached to each one.
What drives the cost of meeting processor duties?
Cost depends on scope and starting point rather than on a single rate. The main drivers are the number of products and environments that process customer personal data, the number of customer contracts that need tailored terms, the state of your logging, access control and encryption, and how many sub-processors and transfers need documented checks. One-time costs usually include the contract template review, the documentation set and any technical remediation. Recurring costs include keeping the sub-processor list current, handling customer audit requests and reviewing changes to the GDPR or to your stack. DeployOpen does not publish prices. A quote follows from the written scope, so ask for a breakdown by deliverable.
Can we handle processor compliance in-house?
Yes, many SaaS companies do much of this internally, especially legal and security teams with GDPR experience. The question is whether your team can cover the technical evidence as well as the paperwork. Internal teams often find the hardest parts are proving how logs, backups and deletion work across systems and confirming that every sub-processor carries the same obligations. Consider outside help for a gap assessment, technical hardening, or preparing evidence for a customer audit. Whatever you choose, the organisation still owns its controls, and only an independent auditor or certification body issues reports or certificates.
What happens when a customer asks to audit us?
Article 28(3)(h) requires a processor to provide the information needed to show compliance and to allow audits, including inspections, by the controller or an auditor it mandates. In practice, most customers start with documentation: the security description, current certifications if you hold them, penetration test summaries and policy extracts. Full on-site inspections are less common but must be permitted by the contract. Agree the audit process, notice periods and confidentiality terms in advance so you can respond consistently. Prepare an evidence pack in advance so each request does not become a separate project.
What to confirm before you accept a quote
DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Before you accept a quote, confirm that the document names the systems and data stores in scope, the tenants or environments, and the personal data categories each one holds. A quote that says only "the platform" leaves open which logs, backups, support tooling and analytics pipelines are covered, and those are often where processor evidence gaps appear. Ask for the scope to state what is excluded as clearly as what is included.
Next, confirm the sub-processor picture the scope will document. Ask how many sub-processors you use, where each one processes or can access data, and which transfers they involve, since the sub-processor list under Article 28 must be something you can name at all times. Confirm in writing whether the deliverables include the processing record that Article 30(2) requires of processors, and a mapping of your processor agreement clauses to the Article 28(3) obligations and to the security measures described for Annex III of the Commission's clauses. Ask for the exact format and the reviewer who will sign off each item. Any figure, count or location you rely on should come from your own inventory and be checked against it, not taken from the quote.
Finally, settle who keeps the evidence current after handover. Records, the security description and the sub-processor list go stale as systems change, so the quote should name the owner on your side, the owner on the partner side if support is retained, and how changes are triggered and recorded. Ask whether ongoing support, upgrades and continuous testing are a separate retainer, and what happens to the scope if a sub-processor changes mid-engagement. Confirm that the partner prepares evidence only and that your independent auditor or certification body is the party that issues any report or certificate.
How DeployOpen prepares SaaS processor evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside a client's own infrastructure. For SaaS companies, we help prepare the systems, controls and written evidence that enterprise customers ask to see, while the organization keeps ownership of its controls and any independent assessment is carried out by an outside auditor or certification body.
How we scope
- We agree a written scope before work starts, listing the processing activities, systems and customer-facing documents included.
- The scope names which Article 28 terms, sub-processors, security measures and breach workflows are in or out of the engagement.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and ongoing support is available as a retainer.
How we build
- We configure and harden the self-hosted platforms that hold customer personal data, including access control, logging and backup and restore.
- We document the technical and organizational security measures so they can be described to customers in a form they can check.
- We help map each processor duty to a system, owner and recurring evidence source, so answers to customer questions point to real records.
How we hand over
- You receive the configuration records, runbooks, sub-processor inventory and breach notice templates in formats your team can maintain.
- We walk your legal, security and engineering owners through the evidence pack so they can answer customer audit requests without us.
- Your organization decides which documents to publish and which evidence to share under confidentiality, and confirms every statement before it goes to a customer.
How we support
- Retainers cover upgrades, periodic review of the sub-processor list and security measures, and updates when customer requirements change.
- We can run security testing of the applications and APIs that process customer data, so findings can feed the evidence record.
- Ask your auditor or certification body to confirm which evidence they will accept, because DeployOpen prepares material but does not issue reports or certificates.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), Articles 28, 33 and 82 ↗
- Commission Implementing Decision (EU) 2021/915 on standard contractual clauses between controllers and processors ↗
- EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR ↗
- EDPB Guidelines 9/2022 on personal data breach notification under GDPR (version 2.0) ↗
- EDPB Guidelines 1/2018 on certification and identifying certification criteria ↗
- Commission Implementing Decision (EU) 2021/914 on standard contractual clauses for transfers ↗
