4 ms·

It's not really a clear statement, and I think it also sort of misses the goal of deletion policies. The above statement for me reads with the implication that

by csydas 5y ago

It's not really a clear statement, and I think it also sort of misses the goal of deletion policies. The above statement for me reads with the implication that it only checks accessibility by the party responsible for the data, as the example check is that the responsible party has no practical means to recovery it. But in fact this is not really a good goal I think as it doesn't really protect against what data retention laws aim for; avoid keeping data you don't need and most definitely don't sell it off. Thus, an attacker looking to do a DB dump will most definitely engage in activities that are not practical to recover inaccessible data; a data sales team will certainly modify the data to still be equally identifiable and targeted but transformed enough that the original dataset is no longer required. It really doesn't address what a lot of data deletion/retention policies aim to succeed with.

dataflow 5y ago
Great point!
xyzzy123 5y ago
Agree I think - the most common mistake people make is just not doing the work. The work means: Understanding the regulatory framework for your ecosystem (and partners), and maintaining policies that align with those requirements. Ensuring that system owners understand the policies, and that they document how they meet the requirements. Ensuring that actual behaviour corresponds to the design and keeping an eye out for errors (if you haven't had to scrub your centralised logging yet you should probably be looking harder...). The intent is not primarily to sweat every detail but to limit gross violations and make sure you're not asleep at the wheel (which is common) or behaving badly. What audits want is evidence you're "doing the work". Be able to clearly explain what you do and why you think it complies. Be able to prove what you say. The details tend get hashed out as a result of following a process. The real-world problems people tend to have are more like "we don't know why we copied all our customer information to that bucket" or "hmm they might have onsold it" or "we don't actually know all the systems that read from this database or what they might copying out it" than "we are concerned about advanced storage necromancy".

by csydas 5y ago

dataflow 5y ago

Great point!

xyzzy123 5y ago

Agree I think - the most common mistake people make is just not doing the work. The work means: Understanding the regulatory framework for your ecosystem (and partners), and maintaining policies that align with those requirements. Ensuring that system owners understand the policies, and that they document how they meet the requirements. Ensuring that actual behaviour corresponds to the design and keeping an eye out for errors (if you haven't had to scrub your centralised logging yet you should probably be looking harder...). The intent is not primarily to sweat every detail but to limit gross violations and make sure you're not asleep at the wheel (which is common) or behaving badly. What audits want is evidence you're "doing the work". Be able to clearly explain what you do and why you think it complies. Be able to prove what you say. The details tend get hashed out as a result of following a process. The real-world problems people tend to have are more like "we don't know why we copied all our customer information to that bucket" or "hmm they might have onsold it" or "we don't actually know all the systems that read from this database or what they might copying out it" than "we are concerned about advanced storage necromancy".