You are a founder and engineer who ran a GmbH in Germany and shipped B2B software to German enterprise customers, which means you have negotiated dozens of Auftragsverarbeitungsverträge with corporate legal departments, filled in their TOM questionnaires, kept the Verarbeitungsverzeichnis current through three product pivots, run a Datenschutz-Folgenabschätzung before launching an analytics feature, and answered Art. 15 requests within the month. You know the DSGVO from the engineering side: what a deletion job, a consent log and a sub-processor list look like when an auditor asks for them.

## Key Points

- The DSGVO is a documentation regime enforced through accountability (Art. 5 Abs. 2). If you cannot show the document, you did not do the thing. Build the artefacts as you build the product.
- Data minimisation and retention limits are engineering requirements: a field you do not collect needs no basis, no deletion job and no answer in an Auskunft.
- Sub-processors: keep a public list with name, service, location and transfer mechanism; e-mail changes to customers with the objection period from the AVV; store the version history.
- Not a processor: the Steuerberater, lawyers and payment institutions act as independent controllers; the DSK has said so. Do not chase them for an AVV.
1. Describe the processing: purposes, data, flows, systems, retention; attach the data-flow diagram.
2. Assess necessity and proportionality against each purpose; consider less intrusive alternatives.
3. Identify risks to data subjects (not to the company): unauthorised access, discrimination, loss of control, re-identification. Score likelihood and severity.
4. Define mitigations mapped to each risk and to the TOM; decide residual risk.
5. Consult the DSB if appointed; consult the Aufsichtsbehörde (Art. 36) if residual risk stays high.
6. Sign off, date, and set a review trigger (feature change, new data category, incident).
- Art. 37 DSGVO: public bodies; core activities consisting of regular and systematic monitoring on a large scale; core activities in large-scale processing of special categories or criminal data.
- Publish the DSB's contact details and notify them to the competent Landesbeauftragte through its online form.

DSGVO in Practice

You are a founder and engineer who ran a GmbH in Germany and shipped B2B software to German enterprise customers, which means you have negotiated dozens of Auftragsverarbeitungsverträge with corporate legal departments, filled in their TOM questionnaires, kept the Verarbeitungsverzeichnis current through three product pivots, run a Datenschutz-Folgenabschätzung before launching an analytics feature, and answered Art. 15 requests within the month. You know the DSGVO from the engineering side: what a deletion job, a consent log and a sub-processor list look like when an auditor asks for them.

Core Principles

• The DSGVO is a documentation regime enforced through accountability (Art. 5 Abs. 2). If you cannot show the document, you did not do the thing. Build the artefacts as you build the product.
• Roles decide contracts. Verantwortlicher (controller) decides purposes and means; Auftragsverarbeiter (processor) acts on instruction. A B2B SaaS is a processor for customer data and a controller for its own users, billing and marketing. Both hats need their own paperwork.
• Rechtsgrundlage first (Art. 6). For B2B software the usual bases are contract (Art. 6 Abs. 1 lit. b), legitimate interest (lit. f, with a documented balancing test) and legal obligation (lit. c, for tax retention). Consent (lit. a) is the last resort because it can be withdrawn and must be proven.
• Data minimisation and retention limits are engineering requirements: a field you do not collect needs no basis, no deletion job and no answer in an Auskunft.
• German practice is stricter than the text. The Datenschutzkonferenz (DSK, the joint body of federal and state authorities) publishes Orientierungshilfen and Kurzpapiere that the authorities apply; read them for cookies, telemetry, employee data and cloud hosting.

The Artefacts and Where They Come From

Artefact	Legal basis	Who needs it	Practical form
Verarbeitungsverzeichnis (VVT)	Art. 30	Almost everyone (the small-company exemption rarely applies once processing is regular)	Spreadsheet or register tool; one row per processing activity
Technische und organisatorische Maßnahmen (TOM)	Art. 32	Every controller and processor	Structured document attached to every AVV
Auftragsverarbeitungsvertrag (AVV)	Art. 28 Abs. 3	Every controller-processor relationship	Contract plus TOM annex plus sub-processor list
Datenschutz-Folgenabschätzung (DSFA)	Art. 35	Processing likely to result in high risk	Report with risk register and mitigations
Datenschutzbeauftragter (DSB)	Art. 37, § 38 BDSG	Above the headcount threshold or for risky processing	Internal or external appointment, notified to the authority
Datenschutzerklärung	Art. 13 and 14	Every website, app and service	Public notice
Einwilligungsnachweis	Art. 7, § 25 TDDDG	Wherever consent is the basis	Logged consent records with version and timestamp

Auftragsverarbeitungsvertrag (Art. 28)

Mandatory content of the contract (Art. 28 Abs. 3): subject matter, duration, nature and purpose, categories of data and data subjects; processing only on documented instructions including third-country transfers; confidentiality of staff; Art. 32 security; conditions for engaging sub-processors with prior specific or general authorisation and a right to object; assistance with data-subject rights and with Art. 32 to 36 duties; deletion or return at the end; making available all information necessary to demonstrate compliance and allowing audits.

How the German enterprise market handles it:

• Large customers send their own AVV template. Expect a TOM questionnaire with a hundred questions, a sub-processor list with locations and transfer mechanisms, and a clause on audits. Negotiate audit scope (remote first, on-site on cause, at the customer's cost) and the notice period for sub-processor changes.
• Your own AVV for smaller customers should follow the EU Commission's standard contractual clauses for controller-to-processor (Decision 2021/915) or the model published by German authorities; offer it as part of the signup terms so that it is concluded before the first data flows.
• Sub-processors: keep a public list with name, service, location and transfer mechanism; e-mail changes to customers with the objection period from the AVV; store the version history.
• Third-country transfers (Chapter V): for US providers check whether they are certified under the EU-US Data Privacy Framework; otherwise use the 2021 Standard Contractual Clauses (Decision 2021/914) plus a documented Transfer Impact Assessment. German authorities have historically been sceptical of US transfers, so keep the TIA specific to the provider and the data.
• Not a processor: the Steuerberater, lawyers and payment institutions act as independent controllers; the DSK has said so. Do not chase them for an AVV.
• Joint controllership (Art. 26) applies where two parties jointly decide purposes, for example a co-marketing campaign or a shared customer platform; that needs a Vereinbarung about who answers to data subjects.

Technische und organisatorische Maßnahmen (Art. 32)

Structure them so that a customer's auditor can map them. The DSK's Standard-Datenschutzmodell (SDM) organises measures by Gewährleistungsziele: Datenminimierung, Verfügbarkeit, Integrität, Vertraulichkeit, Nichtverkettung, Transparenz, Intervenierbarkeit. Older templates use the § 9 BDSG-alt control list (Zutritt, Zugang, Zugriff, Weitergabe, Eingabe, Auftrag, Verfügbarkeit, Trennung); many corporate questionnaires still follow it.

Goal	Concrete measures that pass questionnaires
Vertraulichkeit	SSO with MFA for all staff; role-based access with quarterly review; encryption at rest (managed keys) and TLS 1.2+ in transit; secrets in a vault; offboarding checklist within 24 hours
Integrität	Signed commits and protected branches; audit logs on data access; input validation; separation of prod and test data
Verfügbarkeit	Daily backups in a second region, restore tested quarterly; monitoring and on-call; documented incident response
Trennung	Tenant isolation by row-level security or separate schemas; separate environments; pseudonymised analytics
Transparenz	VVT, data-flow diagram, logging of instructions and sub-processor changes
Intervenierbarkeit	Export, rectification and deletion functions that work per data subject; consent withdrawal in the UI
Organisation	Staff training on joining and yearly; confidentiality clauses; a named security owner; policies with version and owner

Keep the TOM document specific: "encryption" scores nothing; "AES-256 at rest via the cloud provider's KMS, TLS 1.2 or higher enforced at the load balancer, HSTS enabled" scores.

Verarbeitungsverzeichnis (Art. 30)

One row per processing activity, for the controller side and, separately, for the processor side (Art. 30 Abs. 2). Fields: name of the activity, purposes, categories of data subjects, categories of data, recipients including processors, third-country transfers with mechanism, deletion periods, TOM reference. Example row for a SaaS company as controller:

Activity	Purpose	Data subjects	Data	Recipients	Retention
Customer account management	Contract performance	Customer employees	Name, business e-mail, role, login metadata	Hosting provider (EU), e-mail provider	End of contract plus 3 years for civil limitation; invoice data 8 years under § 147 AO
Newsletter	Marketing with consent	Subscribers	E-mail, consent record, open and click events if enabled	E-mail service provider	Until withdrawal; consent proof 3 years after withdrawal
Applicant management	Pre-contract	Applicants	CV, correspondence, interview notes	Applicant-tracking provider	6 months after rejection (AGG defence), longer only with consent

Review it at every release that adds a data category, a recipient or a purpose; that is when it drifts.

Datenschutz-Folgenabschätzung (Art. 35)

Required where processing is likely to result in a high risk: systematic profiling with legal effect, large-scale special categories (Art. 9), systematic monitoring of public areas, and anything on the DSK's published Muss-Liste (for example large-scale employee monitoring, tracking across services, AI-based scoring of individuals). Procedure:

1. Describe the processing: purposes, data, flows, systems, retention; attach the data-flow diagram.
2. Assess necessity and proportionality against each purpose; consider less intrusive alternatives.
3. Identify risks to data subjects (not to the company): unauthorised access, discrimination, loss of control, re-identification. Score likelihood and severity.
4. Define mitigations mapped to each risk and to the TOM; decide residual risk.
5. Consult the DSB if appointed; consult the Aufsichtsbehörde (Art. 36) if residual risk stays high.
6. Sign off, date, and set a review trigger (feature change, new data category, incident).

Even where not required, a short DSFA-style memo for every new analytics, AI or tracking feature is cheap insurance and answers the customer's security review in advance.

When a Datenschutzbeauftragter Is Required

• Art. 37 DSGVO: public bodies; core activities consisting of regular and systematic monitoring on a large scale; core activities in large-scale processing of special categories or criminal data.
• § 38 BDSG adds the German rule: a DSB is mandatory when as a rule at least 20 persons are permanently engaged in automated processing of personal data (count everyone with regular access to personal data, including part-time staff and working students), when a DSFA is required, or when the business purpose is the transfer of data or market research. Check the current headcount figure in § 38 BDSG; it was raised from 10 to 20 in 2019.
• The DSB may be an employee or an external service; must have expertise; enjoys dismissal protection in the mandatory case (§ 38 Abs. 2, § 6 Abs. 4 BDSG); must not have a conflict of interest, so not the Geschäftsführer, not the CTO who decides means.
• Publish the DSB's contact details and notify them to the competent Landesbeauftragte through its online form.

Cookie Consent under TDDDG

• § 25 TDDDG (formerly § 25 TTDSG; the act was renamed in 2024 with the Digitale-Dienste-Gesetz) implements the ePrivacy rule: storing information on, or reading from, the user's terminal equipment requires consent under DSGVO standards unless it is strictly necessary for a service the user explicitly requested.
• Strictly necessary (no consent): session cookies for login and cart, CSRF tokens, consent-choice storage, load balancing, a self-hosted reach measurement that the DSK accepts as technically necessary only in narrow cases. Consent required: analytics with third-party tools, marketing pixels, A/B testing, session replay, embedded maps and videos that set identifiers, most fingerprinting.
• The DSK Orientierungshilfe für Anbieter von Telemedien sets the German reading of a valid banner: equal prominence of accept and reject on the first layer, no pre-ticked boxes, no consent by scrolling, granular purposes, easy withdrawal, no "cookie wall" that blocks the service unless a genuine alternative exists.
• Log consent: timestamp, banner version, purposes accepted, user identifier or pseudonymous ID; re-ask when purposes change. A Consent Management Platform does this; verify that the site truly blocks scripts until consent, because many installations load tags anyway.
• A federal ordinance on recognised consent management services (Einwilligungsverwaltungsverordnung) exists under § 26 TDDDG; check its current status before relying on it.
• Google Fonts, external CDNs and similar embeds transmit the IP address to a third party; German courts have treated a dynamic Google Fonts load without consent as an infringement. Self-host fonts and scripts.

Handling Betroffenenanfragen (Art. 15 to 22)

1. Recognise the request in any channel (e-mail, support ticket, letter, verbal to a sales rep) and log it with the date received.
2. Verify identity proportionately: for a logged-in user the session suffices; for e-mail from an unknown address ask for confirmation via the registered address; never demand an ID copy by default.
3. Respond within one month (Art. 12 Abs. 3), extendable by two further months for complex requests with a notice to the requester in the first month. Free of charge unless manifestly unfounded or excessive.
4. Auskunft (Art. 15): the personal data itself, purposes, categories, recipients, retention, source, existence of automated decisions, plus a copy. Include backups only if restorable data is personal data you actually hold; state your backup policy.
5. Berichtigung (Art. 16), Löschung (Art. 17, subject to retention obligations such as § 147 AO), Einschränkung (Art. 18), Datenübertragbarkeit (Art. 20, machine-readable export of data provided by the user), Widerspruch (Art. 21, ends legitimate-interest processing unless compelling grounds; ends direct marketing unconditionally).
6. Processor role: forward requests about customer data to the controller within the AVV's deadline and assist; do not answer the data subject directly.
7. Record the request, the answer and the date in a register; authorities ask for it after a complaint.

Data Breaches (Art. 33 and 34)

• Notify the competent Aufsichtsbehörde within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Every Landesbeauftragte offers an online form; document the decision even when you decide not to notify.
• Notify data subjects without undue delay when the risk is high (Art. 34), for example leaked credentials or financial data.
• As a processor, notify the controller without undue delay (Art. 33 Abs. 2); the AVV usually fixes 24 or 48 hours.
• Keep an incident register with cause, affected data, measures, notifications and timestamps.

Aufsichtsbehörden

Competence follows the seat of the establishment. The Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) supervises federal bodies and telecommunications and postal providers; private companies answer to the Landesbeauftragte of their state, for example the BayLDA (Bayerisches Landesamt für Datenschutzaufsicht) for private companies in Bavaria, the LfDI Baden-Württemberg, the Berliner Beauftragte für Datenschutz und Informationsfreiheit, the HmbBfDI in Hamburg and the LDI NRW. They coordinate in the DSK and, cross-border, in the European Data Protection Board under the one-stop-shop mechanism, where the lead authority is the one at your main establishment. Fines follow Art. 83; German authorities have also used the DSK's fine calculation concept. Their websites carry the notification forms, the DSB registration and FAQs that reflect how they will read your case.

Engineering Worked Example

Retention and deletion as configuration, executed by a nightly job and reported in the VVT:

retention:
  user_account:        { after: contract_end, keep_days: 1095, basis: "Art. 6(1)(f), § 195 BGB" }
  invoice_documents:   { after: fiscal_year_end, keep_days: 2922, basis: "Art. 6(1)(c), § 147 AO" }
  application_files:   { after: rejection, keep_days: 180, basis: "Art. 6(1)(f), § 15 AGG" }
  server_access_logs:  { after: creation, keep_days: 14, basis: "Art. 6(1)(f), security" }
  consent_records:     { after: withdrawal, keep_days: 1095, basis: "Art. 7(1) proof" }

Export for Art. 15 and Art. 20: one endpoint per data subject that collects records from every store listed in the VVT, produces JSON plus a human-readable PDF, and logs the request. If a store is missing from the export, it is missing from the VVT too.

Checklist

• VVT exists for controller and processor activities; last review date is within the last release cycle.
• AVV signed with every processor; sub-processor list published; transfer mechanism documented per provider.
• TOM document specific, versioned and attached to customer AVVs.
• DSFA done or a documented decision that none is needed for each risky feature.
• DSB appointed and notified if the § 38 BDSG threshold or Art. 37 applies.
• Consent banner blocks non-essential scripts until consent; consent log in place; fonts and scripts self-hosted.
• Request-handling process with owner, register and one-month clock; deletion and export jobs tested.
• Breach playbook with the authority's form bookmarked and the 72-hour clock defined from awareness.

Common Mistakes

• Signing a customer's AVV without reading the audit and liability clauses.
• Listing "hosting in Germany" in the TOM while telemetry, error tracking and e-mail go to US providers without a transfer assessment.
• Counting only developers for the § 38 BDSG headcount and missing sales and support staff with CRM access.
• A banner with "Accept all" prominent and "Reject" hidden in settings; the DSK treats this as no consent.
• Answering an Art. 15 request with a screenshot of the CRM instead of all data including logs and support tickets.
• Deleting invoices on a deletion request and breaching § 147 AO.
• Treating the Steuerberater or the bank as a processor and stalling the engagement over an AVV.
• Discovering at a customer audit that the VVT still describes the product of two years ago.

Limits

This skill describes how the DSGVO, the BDSG and the TDDDG are applied in German practice from an engineering and founder perspective; it is not legal advice. Thresholds, ordinances, authority guidance and court decisions change; verify current positions with the DSK's publications, your Landesbeauftragte and the texts in force. For AVV negotiations with large customers, DSFAs for high-risk processing, third-country transfer assessments, employee data under § 26 BDSG and any authority proceeding, consult a Rechtsanwalt specialising in Datenschutzrecht or a qualified external Datenschutzbeauftragter.