Beyond legal #1: The data protection leader's journey begins

This first post introduces the critical non-legal skills, such as business analysis and stakeholder management, that a Data Protection Leader must master to embed data protection into a global company’s operations.

GOVERNANCEDATA PROTECTION PURPOSE AND STRATEGYDATA PROTECTION LEADERSHIP

Tim Clements

8/13/20255 min read

Beyond legal# infographic
Beyond legal# infographic

This is the first of a series of posts outlining the skills and competences a Data Protection Leader requires (beyond legal knowledge and competences) to embed data protection into the fabric of an organisation. I intend to be jurisdiction-neutral throughout the series but will assume the organisation is a private sector company and a global player operating across multiple jurisdictions.

As we are talking skills, I am aligning where ever possible, with SFIA plus which is a robust skills and competency framework developed by BCS in the UK. The framework is very much geared for those working with information and technology. As a Fellow of BCS, with Chartered status, and a member for nearly 25 years, I've used the framework in various companies over the years and highly recommend you take a look at it. In my posts I will include SFIA codes that you directly reference if you wish, e.g. (BUSA).

This series of blog posts will not cover the legal competences that are required in establishing and running a data protection function in a company. Also, I am not advocating that a data protection leader must possess all the competences I'm going to cover, that is not feasible. To be any kind of leader, leadership skills are essential no matter whether your background is legal, technology, risk, product, etc. - what's most important is the leader can get access to the needed competences when they are required.

A fresh start, or a revamp

Imagine you start afresh as the Data Protection Leader in the company, or you have been recruited by a company where you are tasked to establish their Data Protection Office, department or function and once in place you are accountable for its business as usual (BaU) operation. Let's assume you have no issues to deal with, but if you do a list presented to you on day one, they are always useful ways of eliciting information along the lines of what I'll outline below. A core truth at this point is to recognise that your work will most probably involve business change, and before you make any changes, you need to a thorough understanding of the as-is, or current state.

This realisation is often missed, especially when data protection is anchored in legal departments where you may have a team of top notch legal professionals who, when they studied law at law school were never given tuition in disciplines like business change, programme management, project management, strategy. etc.

The root cause of troubled data protection work further down the line is failing to acknowledge this early on, and it is often the General Counsel who misses this by wrongly assuming that anyone can manage a project or programme. The selection of a data protection leader must take this into account, and in cases where driving change will be an integral part of the role, be mindful not to trivialise this point. If the person to be appointed is not experienced at driving change, then the General Counsel or whoever is responsible must ensure that the leader is supported by one of more experienced change professionals for the duration of the implementation.

Business situation analysis (BUSA)

Your initial step is to grasp the as-is, starting with the business context - your company's mission, objectives and the personal data that fuels the business. This is foundational and the understanding and knowledge you gain here will dictate the relevance and priority of subsequent data protection efforts.

A key reference is studying the company's information resources such as the website, annual report, business strategy documentation, org charts, as well as meeting minutes of recent and relevant governance boards and the existing data protection team meetings. You will need to identify the key senior stakeholders who are responsible for achieving the objectives outlined in the strategy, because you are going to have to get to know them quite quickly.

Beside engaging with who I call the usual suspects (legal, risk, digital marketing, HR IT, IS, etc) I often find engaging with the Enterprise Architecture team can be very revealing because they should be able to explain to you the information needs of the company based on its value chain, and how this is distilled down into technology strategies, architectural standards, development lifecycles and so on.

At the same time, you'll need to get an initial overview of the existing data protection regime in the company. There'll be many questions to ask and preparing and documenting your initial findings is key. This is an art in itself and to do it effectively, getting an experienced business analyst to assist will be beneficial but not essential at this stage. Later, when you have determined the scope of a fuller maturity assessment, the analyst can assist by completing the business situation analysis/investigation with requirements elicitation, prioritisation and sorting, etc.

This is important because you also need to be able to demonstrate that you are making a difference rather than saying you're occupied with conducting an assessment in your first month or two.

Key questions include what is the current budget status, is there a framework, what's the organisational structure, where in the company is data protection anchored, what are the reporting lines, policy frameworks, how does the RoPA look, what supporting tools are there, how risk is managed and what are seen as the key risks, how quality is managed, history of major incidents and breaches, past maturity assessments, etc. There's a lot to cover, and I'll be making a template that can be used in this business situation analysis, in the coming weeks.

I also recommend accessing the level of what I call "legal clunkiness" - this is where legal solutions have been implemented without really taking into account the needs of data subject. A few examples include, generic and long-winded privacy notices, clunky consent banners, generic broad-brush eLearning, data subject facing processes and mechanisms with deliberate friction, generic policies written in legalese, to name a few.

Stakeholder relationship management (RLMT)

You will also need to establish relationships with key stakeholders early on at multiple levels of the company and in particular, you will undoubtedly need to exercise political skills at board-level. The seeds you sow early on will help establish alignment which eventually secures mandate, budget, and cross-functional cooperation so you'll need to get out of your office and put yourself about.

In many companies, the overall perception of the data protection leader is that you are a necessary evil, brought in to ensure your company is compliant. To your face your peers will say your role is important, but when they get back to their own lines of business, or functions, they'll struggle to see the value you bring in the bigger scheme of things. You will therefore need to cultivate a narrative about data protection that will resonate with your peers and their teams. This is where gaining insight about the importance of their work, and their contribution to the achievement of the company's business objectives is a key task before you go round trying to explain why your role is vitally important and that you have the backing of the CxO.

You might want to tailor the narrative depending on whether you are meeting the CHRO, or the CMO, or the Chief Product Officer, CTO, CIO, etc. If you are able to demonstrate to them that you are familiar with their contribution and how critical the processing of personal is in their business area, then you may already begin to see their eyes open after the first couple of meetings that you are not like the last data protection leader they came across who was more comfortable talking in riddles of articles and recitals. Engage with your stakeholder in their context, in their (business) language and jargon.

That's the first blog in the series, more to come.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.