paul78 wrote: » So - unlike your other post which was presumably written by a committee of architects, you are now reading a section undoubtedly written by a committee of lawyers The section is about ediscovery concerns. However, I'm not entirely sure that I necessarily agree that this would be a common issue given the way that many companies would use cloud providers. However in a SaaS model, it's conceivable that as part of e-discovery, access to data such as the provider's logs may pertain to this section. For example, in e-discovery, there could be a request for log information which the client would not have ready access, but would be only available to the provider. The logs may generally not be accessible by the client but are relevant to the client and stored and processed by the provider. And if the log data is in a storage medium that is difficult to retrieve, that could be a concern. There is also a concern that data request would be analyzed because if there is a request for log data, only the relevant log data should be provided and not all log data - ie. ".. should analyze requests for information .... for relevance, materiality, proportionality..." There are also several legal terms used: The word "proportionality" refers to the concept of fairness - best description is here - https://en.wikipedia.org/wiki/Proportionality_(law) And there is also a good explanation of "materiality" here - https://en.wikipedia.org/wiki/Materiality_(law) I'm curious - why are you reading these docs?
ankurj.hazarika wrote: » Store a secure hash. Rather than storing the data directly, store a hash of the data. This allows your program to prove that the holder has the correct value without actually storing it.