Most applications log access events for incident analysis. Correct in principle. The GDPR friction begins where logs contain personal data — and they almost always do. User identifiers, IP addresses, email hashes, session tokens. Article 5 requires a clearly defined retention period. A log bucket without rotation is, legally, an unbounded profile.
Practical fix: define retention at storage level (30 days for access logs, 7 days for debug logs). Configure Loki, Elasticsearch, or equivalent with index lifecycle management. Hash or truncate personal fields before they exit the application boundary.
CRM, mail providers, error tracking, analytics — the average B2B application transmits data to twenty to fifty external services. Post-Schrems II (CJEU C-311/18), signing Standard Contractual Clauses alone no longer suffices. A Transfer Impact Assessment documenting why the destination country provides essentially equivalent protection is required.
Particularly delicate: U.S. cloud providers with European subsidiaries. The subsidiary may sit in Frankfurt; the parent remains subject to the CLOUD Act. Verify actual data-flow routing per service, not just the billing address.
Article 17 — the right to erasure. Most products have a written deletion process. Few have a tested one. The reality check: today, create a test user in production, submit a deletion request through the official channel, and verify in forty-eight hours that every trace has vanished — including backups, log streams, and event queues.
Nearly every architecture leaves residuals. This is less a GDPR question than an architecture question: is there a named data-lifecycle owner per entity?
The Article 28 processor agreement is often adopted from a template and signed. The decisive part — what specific security measures the processor actually implements — lands in Annex 2 as generic prose. "Appropriate encryption" is not a specification; it is a placeholder.
A substantive processor agreement names: password hashing algorithm (at minimum Argon2id or bcrypt with cost ≥ 12), TLS version (≥ 1.2, preferably 1.3), integrity-protected access logging, incident response windows measured in hours. If your processor cannot deliver these particulars, the contract is formally valid and materially hollow.
Article 4 paragraph 5 defines pseudonymization as processing where the link to a person requires separately stored additional information. A monotonically increasing user ID that references the same subject across every database in the stack is not pseudonymization; it is a stable identifier dressed up in vocabulary.
Correct implementation: a separate key table mapping user ID to a pseudonym key, with the analytics database containing only the pseudonym. The additional information lives in a different security zone with strictly limited access.
Article 6 paragraph 1 enumerates six legal bases for processing. Most B2B products reflexively invoke contractual necessity (lit. b) or legitimate interests (lit. f). Either may fit — or neither may fit.
Example. A newsletter tool dispatches a contractual monthly product update. Contractual necessity, valid. The same tool dispatches a "customer success" survey that is functionally marketing. Contractual necessity no longer applies; either freshly collected consent (lit. a) or a documented balancing test under lit. f with clear opt-out is required.
Mapping each data category and processing purpose to a legal basis in a processing record — required in any case under Article 30 — resolves this class of ambiguity.
Article 7 paragraph 4 prohibits making a service contingent on a consent not required to deliver it. Nevertheless, many B2B applications bundle login with marketing opt-in or force tracking cookies at the door.
The clean separation: functional cookies without consent (Article 6 lit. f), everything else behind genuine consent, refusal option as prominent as acceptance, no dark-pattern geometry in the banner.
In our delivery workflow, GDPR compliance is part of the definition of done for every sprint. Each user story that touches personal data passes through a brief privacy review before merge — three questions (legal basis? retention? deletion path?) must have answers. Production data for European customers resides in EU regions. Engineering proceeds with synthetic data. SCCs 2021/914 with Transfer Impact Assessment form the contractual baseline. Our cybersecurity practice and DevOps and cloud infrastructure teams work in lockstep on these topics — privacy and security are not treated as separate disciplines.
Work contracts include the specific technical safeguards as an annex, not as a statement of intent. Fifteen days of free post-delivery bug-fixing covers compliance defects that surface at first production contact.
If your product is heading into a data-protection impact assessment or a certification audit in the coming months, a structured review ahead of the formal examination typically saves weeks of rework. Book a complimentary online scoping session — we'll work through the seven pitfalls against your architecture and provide a realistic effort estimate. The related piece on nearshore software development compared across markets covers the structural question of where development happens.
Article 25 mandates data protection by design and by default — an architecture that is data-parsimonious without user intervention. Article 32 requires appropriate security measures in line with the state of the art. The two overlap but are distinct: Article 25 is structural, Article 32 operational.
An external audit helps when the product is already in production and independent assessment is needed — ahead of certification or a transaction. During development, a better investment is an internal privacy-review template embedded in the definition of done.
Each sub-processor needs its own processor agreement passing through the obligations you hold. Critical point: your primary processor must disclose which sub-processors it uses and allow you to object. Blanket consent without naming falls short of current regulator expectations.
Formally upon material change to any processing activity. Practically, at minimum quarterly. Maintain it as a living document in a Git repository or a compliance tool — not as a spreadsheet in the file share.
It is only mandatory where high risk is likely under Article 35. It is valuable at medium risk — the process forces structured documentation of decisions and provides protective evidence in later audits or complaints.