Most data-mapping exercises begin with the systems everyone recognises: customer databases, HR platforms, document repositories and shared drives. These are necessary, but they are rarely sufficient. PDPL data mapping application logs is the area where we most often see a gap, because applications write personal data into logs, traces and error messages as a side effect of ordinary operation, and almost nobody records that those files exist.
This article is for data-protection officers and application owners at Saudi entities preparing for inspection by SDAIA, the Saudi Data and AI Authority, or answering a data-subject access request. It explains where personal data hides in logging infrastructure, why this creates a retention problem under the Personal Data Protection Law (PDPL), and a three-step method to find and remediate it.
Why logs escape the data map
A data map is usually built from the perspective of the business process: where is customer data collected, stored and shared? Logs do not appear in that view because they are not a business record. They are created by developers and platforms for troubleshooting, monitoring and audit, and they are owned, if at all, by an engineering or operations team that was never part of the privacy workshop.
Three characteristics make them risky:
- Longer retention than the primary record. A customer record may be deleted on schedule while the log lines that quoted it remain in an archive, a backup or a monitoring platform with a different retention setting.
- Wide access. Logs are often readable by developers, support staff, vendors and monitoring tools that would never be granted access to the source database.
- Invisible to subject-access queries. A search built to answer a data-subject request typically queries the systems of record. The same individual's name, national ID or phone number may appear in logs that the search never touches.
Log types that commonly leak personal data
The pattern varies by technology stack, but the same categories appear repeatedly.
- Application error and exception logs. Stack traces and error messages frequently include the input that caused the failure, such as a name, email address, identity number or account number entered in a form.
- Debug and verbose logging. Debug levels enabled to resolve an incident are sometimes left on. They can record full request and response payloads.
- API gateway and integration logs. Request bodies, query strings and headers can carry identifiers, tokens and personal attributes, especially where identifiers are passed in URLs.
- Web server and proxy access logs. IP addresses, device details and URLs containing user identifiers are recorded for every request.
- Authentication and session logs. Usernames, login attempts, device identifiers and location indicators.
- Database query and slow-query logs. Statements with literal values inserted, including personal data in search conditions.
- Monitoring, crash-reporting and analytics tools. Third-party platforms that receive copies of errors and sessions, sometimes hosted outside the Kingdom.
- Support tooling. Ticket attachments, screenshots and chat transcripts that capture personal data and are retained separately.
The last two deserve particular attention. Where logs are shipped to a service hosted abroad, the cross-border transfer provisions of the PDPL become relevant. The law can also reach processing outside the Kingdom of personal data relating to individuals in the Kingdom, so hosting location does not remove the obligation.
The retention problem
The PDPL, enforced by SDAIA, requires that personal data be kept only for as long as the purpose for which it was collected requires, and that it be destroyed once that purpose is fulfilled. Our reading of the law is that this principle applies to data wherever it sits, not only to the designated system of record. Whether a specific provision is cited as Article 6(1) or elsewhere in the law and its Implementing Regulation should be confirmed against the current text with legal counsel before it appears in a formal response.
The practical consequence is straightforward. If a retention schedule says customer identity data is deleted twelve months after account closure, but error logs containing that data are kept for five years, the entity is holding personal data beyond its purpose. It also cannot honestly state that the data was deleted. A log archive that nobody has mapped is a retention exposure that the organisation does not know it has.
The same gap affects data-subject rights. If a person requests access to, correction of or deletion of their data, the response is incomplete if it ignores places where that data is demonstrably held.
A three-step method
Step 1: Inventory the logging estate
List every application, platform and service that generates or receives logs, and for each record where the logs are written, who can read them, how long they are kept, whether they are backed up and whether they are sent to a third party or outside the Kingdom. Include the sources that sit outside the main engineering team, such as vendor-hosted applications and support tools. The output is a register of log sources with an accountable owner for each.
Step 2: Sample and classify the content
For each high-risk source, inspect real log content rather than relying on what the application is believed to record. Search for patterns such as national ID formats, mobile numbers, email addresses and names in free-text fields. Check what happens when an application fails with unexpected input, because error paths are where the least careful logging usually lives. Classify each source as containing no personal data, incidental personal data, or regular personal data, and record the categories found. Where sensitive data is present, treat the finding as higher priority.
Step 3: Remediate and keep it under control
Remediation has four parts:
- Stop the source. Change the code or configuration so personal data is not written: mask or truncate identifiers, remove payload logging, disable debug levels in production and keep identifiers out of URLs.
- Set retention. Define a retention period for each log class that matches its operational purpose, and enforce deletion in the logging platform and in backups.
- Restrict access. Limit who can read logs containing personal data and record that access.
- Add the logs to the map. Reflect each log source in the data inventory, the records of processing and the procedure for handling data-subject requests, so that future searches include them.
Then make it durable: add a logging standard to the development lifecycle and a review checkpoint for new applications and integrations.
When to act and what good looks like
An entity should address this when it is preparing for an SDAIA inspection, when a data-subject request exposes data in unexpected places, after an incident in which logs turned out to hold personal data, or when a data map has been completed without any reference to logging, monitoring or support tools. Other signs are applications with verbose logging that nobody has reviewed, and log retention that is set by platform defaults rather than by decision.
A good outcome is concrete. Every log source that holds personal data is known and owned. Retention is defined and enforced. Access is limited. Subject-access procedures search the right places. And the entity can show an inspector how it got there, not only that it has a policy.
How we approach it
Log analysis fits within our Personal Data Protection (PDPL) service, which covers data mapping, records of processing, data-subject rights and breach response. The work produces a personal data inventory and data-flow maps, records of processing activities, privacy notices and a consent approach, data-subject rights and breach response procedures, and a staff awareness session. These are built around a clear inventory of personal data and where it flows, and controls integrated with your security program. Programs of this kind run for 6–8 weeks. We assess your specific arrangements, including where systems are hosted outside the Kingdom.
Next step
If your data map stops at databases and file shares, the logging layer is the place to look next. Our Personal Data Protection (PDPL) service can help you extend the inventory to cover it and prepare for inspection or a subject-access request with confidence. Contact CISO Consulting to discuss the scope.
