Confusion over patchwork legislation and terminology can lead to inactivity in operationalization of privacy as a result of the inability to assign roles and responsibilities.
If a Chief Privacy Officer is not required by legislation, who is responsible for organizational privacy programs, practices and outcomes? Ultimately, each organization decides how best to manage programs and when, or if, to track and report on outcomes. How does a data subject learn about how their information is managed at a given organization, and from whom? Such processes vary substantially from organization to organization.
Without access to, or consistency of, this information, it seems unlikely that a data subject could make informed decisions about privacy, or give meaningful consent.
The duality of a privacy professional’s role combined with the variety of organizational cultures results in a number of different combinations of depth, quality, breadth, nature and application of operational privacy.
Privacy programs have no set criteria, metric or descriptive quality.
The same conditions that enable customization bring the lack of transparency for the data subject. How do I know if Hotmail and Gmail manage my information in the same way? Or if they do it differently, how do I know if that difference matters to me? Information provided in privacy policies is often vague and lengthy.
There are other privacy problems that manifest for data subjects when organizations try to respond to privacy requirements under legislation.
Applying privacy legislation to service organizations means that front-line staff should be educated and empowered to discuss privacy with data subjects. For example, when a store clerk asks for my zip code, s/he should be able to explain where it goes, who has access to it and why. Moreover, what are the implications for sharing or not sharing that information? Otherwise, a data subject cannot meaningfully provide consent to sharing that information. Imagine the store lines if this were the case now. The advent of cloud computing makes consent even more complex, particularly if the cloud services are outsourced or sold through a reseller.
Privacy legislation sets out the rules for managing information, but this is predicated on the assumption that the initial collection of PI was lawful and appropriate. Even then, traditional computing schemes like role based access controls are difficult to implement in environments where there is a hierarchical service delivery model. For example, one person may work directly with the customer while another is responsible for data input. The data subject may assume their point of contact is the only person they are consenting to see their data.
Breach notification requirements vary procedurally.
For example, characteristics for what constitutes a breach are not set out by legislation. An unauthorized access by a staff person may or may not require notification, depending on the organization’s practices and internal policies.
Further, the mechanisms for identifying breaches, for example, back end logging, may increase the risk of breach itself by creating more records of PI.