My previous posts introduced GDPR concepts and the SDL Tridion DX features or capabilities impacted by GDPR. In this post, I'd like to share some organizational recommendations that go beyond any specific technology. This is by no means a comprehensive guide but it can highlight important privacy practices to consider such as:
- Privacy by Design
- Learning and Training
Before looking at these practices, let's put "GDPR compliance" into context as a familiar process that follows a series of steps.
Having seen several regulatory or nonfunctional requirements in customer implementations or past projects, I’ve found most follow some-to-most of the following steps.
- Become informed. The first step is to understand the regulation or requirement from different aspects. This helps to put the requirement in context and see the extent of the impact on your organization. This might relate to a specific feature, product, or service or start with a small research project.
- Get guidance. As you learn more about the regulation or requirement, you might find you already have resources that can give you practical advice and guidance within or outside your organizations. Perhaps your IT partner handles similar requirements for their other companies or one of your groups already meets the same or similar requirements. If looking for external help, be sure to find a vendor, contractor, or consultant you trust. Be wary of solutions that offer a one-time, automated “fix.” Regardless of the approach, be sure to secure executive sponsorship for the requirement or practice.
- Prioritize the work. You might start by making sure all new work adheres to new or revised practices. You will also need to prioritize the backlog of existing feature, products, or services by size and/or impact. Tools or some type of automation might help, but a lot of requirements depend on manual checking as well as interpretation of practices developed over time, often by precedence or through a surrounding community.
- Join a community. There’s often a community that surrounds a given requirement such as “Accessibility” or “Search Engine Optimization.” The same applies to practices such as “Scaled Agile Development.” This includes organizations, governance boards, and online communities.
- Improve the practice. You will complete your initial projects and improve the practice across one or more groups. In the long run, however, you may eventually lead and define aspects of a given requirement or practice in the larger community.
I’ve seen this rough process apply to things like health privacy regulation (e.g. HIPAA), accessibility (e.g. Section 508 Compliance), SEO, Web analytics, and agile practices. As with any practice, be wary of myths while avoiding a myopic focus.
For GDPR compliance, start your review and implementation of any necessary changes to comply with GDPR by realizing that any modern website already complies with many practices that promote privacy and transparency. You might already have roles, processes, and procedures to support existing regulations and policies such as COPA (The Child Online Protection Act) or HIPAA (Health Insurance Portability and Accountability Act) in the United States or the previous Privacy Regulation that covered European member states.
Mapped to steps I outlined above, your “path to GDPR compliance” may involve the following.
- Become informed. This series could be a small part of your research. I would expect medium-to-large companies to have their own “GDPR” research projects.
- Get guidance. Though GDPR has been public for a few years now, it hasn’t been enforced yet (as of March 2018). For expertise, I would look to those with a Data Privacy background or role, information security expertise, or your existing products or services that already work with data subjects.
- Prioritize the work. For GDPR, it’s important to focus on your products or services that deal with either the most customer data or sensitive data. Risk might be an important consideration as well.
- Join a community. Privacy practices depend on your systems and use cases, but consider joining the implementation communities of your vendors as well as the communities that surround your specific industry and/or information security.
- Improve the practice. It is early days for GDPR. But you can already see how the largest internet companies handle their customer’s privacy. For example, see my old post highlighting some of the privacy control that Amazon, Facebook, or Google five years ago.
Now that we’ve explored some steps for addressing a requirement like “privacy regulation,” let’s look at privacy by design.
Privacy by Design
Privacy by design is a concept that suggests keeping privacy in mind from the start of your projects, implementations, products, or services.
This includes practices such as:
- Data minimization which limits access to data by role or purpose
- Pseudonymization which reduces the ability to associate data with a specific person
- Limited processing which ensures you only process data according to explicitly agreed-upon purposes
- Data retention which keeps data for as long as needed
- Secure data deletion which disposes of data safely
- Self-service which gives data subjects the ability to amend, correct, or update their data
Learning and Training
Read the GDPR text and revisit your current internal privacy policies. You'll want the departments or groups such as support, development, product management, content owners, and especially contact managers to understand the impact of GDPR and the importance of data subject privacy.
Be sure anyone who works with customers understands that users from the EU have certain rights to their data (for global companies this might as well be all users). You should limit who has access to Data Subject details to those who need the information. You can use authorization in Tridion Sites as well as field-level control to fine-tune Audience Manager contact details, for example.
Be sure you have policies and procedures in place on how to move, share, anonymize, and/or pseudo-anonymize data between you and other companies. When sharing a database with customer data for troubleshooting, you should “scrub” or anonymize personal data. In other cases, you may want to pseudo-anonymize data that leaves data intact, but difficult-to-impossible to identify as a specific user.
As mentioned in the first post, we are literally "in this together" and SDL itself has been training its staff and revisiting privacy practices and procedures.
To ensure transparency and accountability for your data subjects, you might update Terms & Conditions and Privacy Statements, but do not rely on them for "blanket" disclaimers or permission to use private data. It's important to offer your customers explicit opt-in options.
Be sure to always obtain explicit permission before processing personal data. For example, you'll want to place opt-in text and checkboxes as close as possible to where you solicit permission for users. Avoid assuming agreement and do not present preselected opt-in checkboxes.
Use plain language when explaining possible choices to users. Also, make it easy for users to find what they already agreed to at a later time.
Consider using dates, identifiers, or other ways to track explicit opt-in choices by your users. For example, you will want to be able to confirm that a given user agreed to the company newsletter on a given date.
Be sure to also consider personal data stored or processed by other systems or companies. As an example, our own editorial team for SDL.com uses SDL Tridion Sites to manage the placement of contact forms on its pages along with CRM and Marketing Automation systems to record details for visitors. To improve this experience, we are adjusting the same systems to store more granular opt-in preferences.
The GDPR text is mostly agnostic to how or where you store such opt-in preferences, so find an approach that works for your existing systems.
Seeing the steps to compliance as a familiar process can put practices such as privacy by design, education, transparency, and accountability in context, which you can address at a high-level across your organization. Your technical implementers, however, may be interested in recommendations specific to SDL Tridion DX features such as Audience Manager, the Ambient Data Framework, or User Generated Content. I will revisit these features in my next post.
These blog posts are meant to help SDL customers familiarize themselves with the concepts and high-level requirements of the General Data Privacy Regulation (GDPR). Following these recommendations can help organizations follow good privacy practices. But this should not be treated as legal advice or a comprehensive and exhaustive checklist for “GDPR compliance.”
All organizations are encouraged to read the GDPR from legal, business, and IT perspectives, to confirm how to best comply with the regulation to ultimately protect and safeguard the privacy of the people that interact with them.
Find my others posts in my introduction to the SDL Tridion DX GDPR Blog Post series.