PrivacyOps

WHAT IT IS. Privacy operations is the day-to-day work of honouring commitments about personal data: maintaining an accurate picture of what you hold and why, deleting it on schedule, answering requests from the people it describes, and involving engineering early enough that privacy is a design input rather than a retrofit. WHY IT EXISTS. Privacy failures are rarely malice; they are usually inventory failures. A team cannot delete data it does not know exists, and the copy nobody remembers — the analytics export, the debugging dump, the third-party sync — is the one that surfaces in a breach. Written commitments accumulate faster than the systems that must honour them, and the gap only becomes visible when someone exercises a right or a regulator asks. WHEN TO USE IT. The moment you hold data about identifiable people, which for most products is immediately. The scope grows with jurisdictions and with the sensitivity of the data, not with company size. A startup handling health or children's data needs this earlier and more thoroughly than a larger company selling to businesses. WHO OWNS IT. A privacy owner — sometimes a data protection officer, sometimes a legal or security lead — owns the register, the retention schedule and the request process; engineering owns the deletion paths and the data flows; product owns the choice to collect in the first place, which is where most privacy debt is created. Legal interpretation of obligations sits outside this area; the operations described here execute decisions that legal makes. WHAT GOOD LOOKS LIKE. A data inventory exists, is refreshed by something automatic rather than a yearly survey, and names a lawful basis and a retention period for each category. Deletion is a tested code path, not a manual runbook, and it reaches backups and derived stores on a defined timeline. Data-subject requests have a measured turnaround well inside the statutory clock. Privacy review is a normal step in design for features touching personal data, and it produces changes often enough to prove it is real. Vendors that process personal data are known, and the list is current. HOW TO IMPLEMENT. Start with an honest inventory of the top ten data flows, including the ones that embarrass you — exports, logs, support tooling. For each, record purpose, lawful basis, retention and destination. Implement one deletion path end to end and test it as you would a restore, including the backup horizon. Stand up a request intake with a clock and an owner, and measure turnaround from day one. Add a lightweight privacy checkpoint to design review — see /checklists — and make minimisation the default by questioning each new field at collection. Where AI features are involved, be explicit about what leaves your systems; the boundaries described in /devsecops apply. HOW TO ASSESS YOURSELF. Could you produce, today, a list of every system holding customer personal data and the retention applied to each? If a deletion request arrived this morning, what is your realistic turnaround, and does it include backups? When did a design review last change because of a privacy concern? Score yourself at /assess and sequence remediation with /roadmaps.