Personal data protection: obligations, third parties, and evidence. What to request and how to audit

In most organizations, the protection of personal data has ceased to be an exclusively legal issue and has become a critical component of the operating model. 

In fact, it is considered a key dimension of data governance, which defines how data is managed, controlled, and used throughout the organization

However, a significant gap still exists between what is defined in policy and what actually happens in production. gap Not only does it expose the organization to regulatory risks, but it also limits its ability to scale data, analytics, and artificial intelligence initiatives in a controlled manner.

In a context where data circulates between multiple systems, teams, and third parties, this article proposes a practical approach: How to move from declaration to control, and from control to evidence.

The problem: compliance isn't about declaring, it's about being able to prove it.

One of the most frequent tensions in audits is the difference between “documentary compliance” and “operational compliance”. 

Many organizations may show policies, procedures, and contracts that formally meet the requirements, but fail to demonstrate that those guidelines are effectively applied in daily systems and processes.

This difference becomes critical when an incident occurs or when a regulator demands traceability. 

In these scenarios, what is being tested is not the existence of a policy, but the ability to reconstruct concrete facts: 

• Who accessed the data and under what authorization.
• Which controls were active.
• What actions were taken in response to a deviation?.

The central point is that Actual compliance is observable and auditable. Without records, traceability, and defined responsibilities, any policy loses practical value. 

Therefore, the protection of personal data must be designed from the outset as an evidence-based control system, not as a set of static definitions.

What obligations exist and how do they translate into operational controls?

Obligations regarding protection of personal data They are usually formulated in broad terms: protect confidentiality, guarantee integrity, limit use, and ensure availability. 

The challenge is to translate those principles into concrete decisions that impact architecture, processes, and daily operations.

For example, data classification is not just a conceptual exercise, but the basis for defining which controls apply in each case. 

Without a clear classification system, all data is treated the same or, worse, without any consistent criteria. This directly impacts the prioritization of controls and the allocation of resources.

Access control, on the other hand, requires going beyond the initial assignment of permissions. It involves Periodically review who has access to what., to understand if those accesses are still necessary and to detect accumulations of privileges that increase the risk. 

In dynamic environments, this control must be integrated with processes for adding, deleting, and modifying users.

Data minimization forces us to question common practices: what data is collected, for what purpose, and for how long it is kept. Often, the problem is not misuse, but unnecessary accumulation that expands the risk area.

Regarding retention and deletion, The challenge is not in defining policies, but in implementing them in an automated way.. The absence of technical mechanisms to ensure the effective elimination of data means that policies remain merely declarative.

Traceability and incident response complete the picture. Without adequate records, there is no way to investigate or learn from events. Without clear response processes, even minor incidents can escalate in impact.

Third parties and suppliers: the weakest link and how to manage it

As organizations adopt service-based models - cloud, SaaS, partner integrations - the perimeter of control expands. 

This implies that a significant part of data processing occurs outside the organization's direct infrastructure.

Thus, third parties become a critical point. Not only because of their access to data, but also because of the complexity of their own supply chain. 

A provider may, in turn, depend on multiple subprocessors, making visibility and control difficult.

The most common mistake is assuming that hiring a reputable vendor automatically guarantees compliance. In practice, each organization must... validate that the third party's controls are equivalent to your own and that there is evidence of its functioning.

This involves working on three dimensions:

• Contractual: clearly define responsibilities, service levels and audit rights. 
• Operation: establish monitoring and periodic review mechanisms. 
• Evidence: have concrete evidence that the controls exist and work.

Third-party management is not a one-off process, but a continuous cycle of evaluation, monitoring, and adjustment.

What evidence do you need to audit data protection?

Evidence is the bridge between intention and reality, allowing us to validate whether controls are working and to identify deviations in time. 

How is evidence constructed?

• The access logs They are one of the most critical pieces of information, as they allow us to reconstruct who interacted with the data and in what context. However, simply having them is not enough: the logs must be complete, consistent, and accessible for analysis.
• The treatment records They provide context about the use of the data: what it is used for, who is responsible, and under what conditions. This is key to evaluating the legitimacy of the processes.
• Versioning and configuration They allow us to understand how systems and controls evolve. This history makes it easier to identify when a change was introduced that could have created a risk.

The evidence should also include the security controls applied, such as encryption, authentication, or monitoring, as well as the results of previous audits and the incident management.

A key aspect is that evidence should not be a manual effort generated solely for audits. It should be part of the normal functioning of the operation and be generated automatically and continuously.

How to audit in practice: process, responsibilities and frequency

An effective personal data protection audit requires a structured, yet pragmatic, approach. The key lies in prioritizing based on the risk and criticality of the data.

The first step is to clearly define which controls will be evaluated and what evidence supports them. This helps avoid superficial audits based on perceptions or statements.

Regarding those responsible, it is essential that the audit be a coordinated effort in which:

• Safety provides the technical perspective.
• Compliance interprets regulatory requirements and data teams.
• Architecture validates the implementation.

The audit frequency It must be adapted to the level of risk. Critical systems require more frequent reviews, while others can be evaluated over longer cycles. The important thing is that there is a sustained and predictable cadence.

Finally, the documentation of findings This is key to transforming the audit into an improvement tool. Each finding must be translated into a concrete action, with defined responsibilities and deadlines.

Checklist: If there is no evidence, there is no compliance

This checklist serves as a quick validation of the maturity level. It's not just about verifying the existence of controls, but about confirming that they can be demonstrated at any time.

As a premise, it must be taken into account that if you don't have the evidence, there is no compliance:

• You have an inventory and classification of data (sensitive and non-sensitive).
• You defined who accesses which data and it is controlled by each role.
• You can display access and data usage logs.
• You have retention and deletion policies in place.
• Third parties have equivalent controls and you can prove it.
• You have contracts with data protection and audit clauses.
• You record incidents and have a response plan.
• You can reconstruct what happened in the event of an incident (traceability).
• You have clear responsibilities: data owner, security, compliance.

This type of checklist allows for quick alignment of the areas involved and the detection of gaps without the need for complex processes.

Common mistakes that put the organization at risk

One of the most common mistakes is treating personal data protection as a compliance requirement addressed at the end of projects. This leads to solutions that are neither designed to be audited nor to scale.

It is also common to delegate to suppliers without validating their controls, which creates a false sense of security. The lack of logs and auditing mechanisms is another critical problem, because it prevents the detection and analysis of incidents.

On the other hand, the absence of ownership Clearly, this creates ambiguity: if no one is responsible, controls tend to degrade over time. 

Finally, failing to integrate privacy into the development cycle means that each new product or feature increases the risk.

In environments where data feeds AI models, these errors not only affect compliance, but also the quality and reliability of the results.

Next step

In personal data protection, the difference between an exposed organization and a prepared organization It's not about what he declares, but about what he can demonstrate, sustain, and improve over time.

To transform the guidelines into concrete actions, the next step is to structure the audit with practical tools. Schedule a work session to review evidence, detect gaps, and define a remediation plan.