Data Protection and Service Management

Data protection has become an increasingly central part of organizational operations, yet challenges related to resources and budgets remain all too familiar. According to the IAPP Privacy Governance Report 2024, the workload of privacy professionals has grown significantly, while resources and budgets lag behind.
In many organizations, privacy management is handled in a decentralized manner across different systems—or even manually using Excel spreadsheets, making tracking and reporting difficult. Does this situation sound familiar in your organization?
Privacy function’s resource problem
IAPP‘s (International Association of Privacy Professionals ) annual Privacy Governance Report has been available on the IAPP website for a while. The respondents are privacy professionals responsible for the privacy in their respective organizations. 81 % of respondents say that responsibilities (see the picture) have increased and expanded and that they are struggling with budget and resources.

Resource and budget problems are probably worse than they could be, because in general organizations seem to do this work either in separate systems or through dozens of Excel forms and completely removed from the organization’s daily work related to the context that should be controlled.
If you are one of these 81% or otherwise feel the same, I recommend developing cooperation with your organization’s IT department and especially with those responsible for service management and service leadership.
To manage their own territory, these parties should already collect and maintain information about the context of data protection and information security in the service management system or systems. Examples of context:
- customers
- own organization structure
- processes
- services
- information about the stored data (e.g. where the data is stored)
- technologies
- suppliers
- infrastructure
- etc.
Build up of need for controls
At the end of the day, compliance is basically about the fact that in addition to internal risk management, government agencies carry out their own risk management and churn out directives and laws to control those risks, which then become binding on the organization either directly or through contracts.

Based on the organization’s own risk management and external directives, laws, standards, and agreements – the controls are then formed to manage something (the subject of the control) in the context of the organization. For example, “critical service” and other related things such as technologies, suppliers, supplier agreements, infrastructure, instructions, processes, etc.
This information of the context should already be at a good level in the service management system/systems, because services are produced based on that information.
Compliance management
Each service management system has its own data model for monitoring compliance, but conceptually we have
- Source document (e.g. Data Protection Act)
- Parts of the document (e.g. a specific paragraph or clause depending on how detailed you want to go)
- Risks (identified by your own organization)
- Controls that meet the requirements of the source document, or which control the identified risk
- Subject of the control, which is something in the context of the organization that is usually already managed in the service management system in terms of information (service, system, supplier, contract …)
- Control verification, i.e. evidence of checking the control at regular or irregular intervals

Example
Similar requirements come from several sources written in different styles. Those requirements can usually be satisfied, at least in part, with COMMON controls that can be verified only once and are glued to the context managed by the control.
In this way, as an organization, we can track WHY we do certain things and in a certain way. A Control is by its nature a requirement for something.
Those responsible for risks, information security, and data protection benefit from using the same system, as the daily work of the IT department should maintain the context that they are responsible for controlling. In addition, if a customer is lost and the contract has brought obligations that we do not otherwise have, the organization can easily monitor whether a control can be removed. Control always costs money and effort after all.

Julkaistu 25.02.2025