StableSeguridadprivacy

Privacy — Personal Data as an Engineering Constraint

Turns EU data-protection law into checkable rules for the parts a codebase actually decides: which fields exist, why, who they go to, how long they live, and what happens when someone asks for them back.

gdprprivacypersonal-datalawful-basisconsentdata-minimization

Principios

· P1 — Personal data is anything that can single out a person, not just the obvious fields. An IP address, a device identifier, a session cookie, a support-ticket screenshot, and a "user_1847" analytics event are all in scope. Teams under-scope this by picturing name-and-email and missing the four other places a person is identifiable.
· P2 — Every field must name why it exists before it is collected. Not what it might be useful for. A column with no stated purpose has no lawful basis, no retention rule, and no one who will notice when it leaks.
· P3 — Collection is the decision that cannot be undone. Encryption, access control, and deletion jobs all reduce risk after the fact. Not collecting removes it. The cheapest privacy control in the system is the field you didn't add.
· P4 — Privacy is a schema property, not a policy document. A retention promise that lives only in a policy page will be false within a year. If it isn't a constraint, a job, or a test, it isn't a rule — it's a hope with a publication date.
· P5 — Consent is one lawful basis among several, and usually the weakest one to build on. Contract necessity and legitimate interest carry no withdrawal mechanism to implement. Choosing consent means committing to capture it, record it, honor its withdrawal, and function without it.

Patrones

· Don't collect it. The strongest privacy control available at any moment is the field you decline to add. Every other control is damage limitation on a decision already made.
· Ask "what breaks without this field?" before "where do we store it?" If nobody.
· Reach for a lawful basis other than consent when one genuinely fits. Contract necessity for things the product cannot do without is honest and carries no withdrawal mechanism to build. Consent for things the user can meaningfully decline is honest too. Consent as a blanket wrapper over everything is neither.
· If the cookie banner is the privacy work, there is no privacy work. The banner is the most visible and least important part. The schema, the retention jobs, and the deletion path are where the exposure lives.
· Assume every analytics event will eventually be joined to a user. Design it pseudonymous now, because the join is one product request away and by then the history is already personal data.

Riesgos

· Ver anti-patrones específicos del dominio en el pack.

Checklist

[ ] Every personal-data field is in an inventory with purpose, lawful basis, retention, and destinations. (PR1)
[ ] New personal-data fields are justified at review, not added speculatively. (PR2)
[ ] Each processing purpose names a lawful basis chosen before implementation. (PR6)
[ ] Consent records store scope, wording version, timestamp, and method — not a boolean. (PR7)
[ ] Consent is unticked by default, granular, and reject is as easy as accept. (PR8)
[ ] Withdrawal actually stops the processing, downstream included. (PR9)

Fuentes

En la bibliografía AKOS

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

Explorar todas las fuentes →