Manage Learn to apply best practices and optimize your operations.

Development teams at risk for making privacy agreement violations

Security expert Dan Cornell says end-user privacy is a concern for many development teams and gives great advice on how to protect it.

How do security and privacy intersect? How do we ensure we're not violating our own end-user privacy agreements?

Security and privacy intersect with an organization's responsibility to protect their customers' sensitive data. In broad terms, security typically requires that this data not be inadvertently disclosed to unauthorized parties and privacy typically requires that this data not be misused – intentionally or otherwise. Obviously this description glosses over a myriad of subtleties, but it can provide a starting framework for addressing end-user concerns about how their data will be handled and communicated.

Many organizations only really start to think about privacy after they have had some sort of high-profile incident.

Focusing on system security is important because disclosure of sensitive data often has privacy implications. Protecting privacy requires that policies be created to describe how data can be used and that the associated business processes and support systems be created in such a way that these policies are enforced.

With regard to protecting your own end-user privacy agreements, the first question to ask is: "Have my developers read our privacy policy and do they even know it exists?" Legal counsel, in consultation with marketing and other business functions, typically drafts privacy agreements. The contents of the agreements are often not explicitly communicated to the teams building the systems that handle data with privacy implications.

If development teams do not know how this data should be treated, organizations should not expect that the systems they build will treat it properly, either. Organizations' data classification policies need to describe what data inside an organization has privacy implications as well as how that data should be stored, transferred and made available to both in-house and third parties.

Organizations need to evaluate internal systems and external providers in order to identify those that deal with credit card information in support of the payment card industry (PCI) compliance process. They also need to look at these systems through the eye of their own privacy policies. What systems receive this data? How is the data stored? Under what circumstances and conditions is it made available to internal users and external partners?

The challenge is that privacy and PCI are addressed differently. In many organizations, PCI compliance is a high-profile concern that receives management attention and associated budget. In contrast, many organizations only really start to think about privacy after they have had some sort of high-profile incident, a security breach or other gaffe. This has a tendency to result in large data compromises that can be difficult to clean up.

However, if system designers and developers are proactively made aware of privacy restrictions, many of these problems can be addressed before they occur. This may necessitate changing or eliminating system requirements in cases where business users want to be able to interact with data in ways that run counter to published privacy policies. It is better to inconvenience these business users than to allow the restrictions imposed by privacy policies to be circumvented.

Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Does your development team prioritize end-user privacy agreements?