But where does the DPA fit in?

In yesterday’s post, I suggested that it was time for businesses to recognise and setup a new role – the Data Protection Advocate (DPA). This would be the key person tasked within the organisation to think of data protection scenarios, potential gaps, etc., and be the advocate for ensuring that data generated by or on behalf of the company is protected.

However, a DPA by him or herself is probably not going to achieve much within an organisation, so the next step is to try to work out where the DPA fits within the organisational structure. For that, we need a diagram. And here’s one I prepared earlier:

Assuming there are multiple backup administrators within an organisation, there will be fewer DPAs than there are administrators. So, nominally, backup administrators will in some way or another report through to the DPA.

The DPA would logically need to liaise with a large group of people within the organisation. At bare minimum, this would be:

• Key users – These are the people in each business group who just “know” what is done. They’re the long-term people, the “go to” people within each department. They’re going to have a lot of intrinsic knowledge that the DPA should be regularly mining.
• Function owners – Previously we’d have called these people the department heads, but functional ownership within businesses is shifting to be broader as traditional employee/management interaction continues to change, so “function owners” seems more appropriate.
• IT Team Leaders – IT obviously represents a significant portion of the data iceberg within a company, and therefore the DPA should be liaising with each of the team leaders – including storage, virtualisation, networking, security, etc., as well as the traditional server teams.
• HR/Finance – Smaller organisations traditionally see HR and Finance as a combined group. In larger organisations this will obviously not be the case. Regardless, both HR and Finance will have a very strong understanding of the types of data they need kept and protected. You could argue that this is no different from any other group, but HR and Finance data is usually at the core of the “business critical” data we protect, and thus deserve to be singled out.
• Legal – Somewhere, someone has to have an understanding of the legal ramifications of (a) choosing not to protect some data or (b) how long data should be kept for. In larger organisations, IT people should be able to consult with someone from corporate legal to get a very clear and straight forward answer.

The DPA however does not work in isolation once the requirements have been gathered. This person will then coordinate with (and be a voting member of) the Information Protection Advisory Council. That will be a group of reasonably senior people within the organisation from across a spectrum including IT, Finance and traditional business functions, who are empowered to make decisions that affect the entire company in relation to data protection policies on behalf of the board. For want of a better term, this is the “policy team” for data and information protection. You’ll note that I’ve switched at this level from referring to Data Protection to referring to Information Protection. That’s quite deliberate. The DPA will be concerned with the minutia of data within the organisation. The IPAC should be able to focus on the broader information view, instead.

Logically, this group will sit at an organisational level on par with the most senior Change Control Board. That board will, for the average organisation, report directly to the CIO.

So there you have it – a new role, and a new group.

Have you appointed a DPA yet? Have you started forming your IPAC yet? If not, get cracking!