How to Design Privacy-Safe Application Logs in Saudi Arabia and the UAE

Application logs can answer the question everyone asks during an incident: what happened? They can also become a second, poorly governed copy of customer data.

That risk is easy to miss. A developer logs a request body to diagnose a failed checkout. An identity service records an access token. A support tool stores a customer's email beside a stack trace. The records then flow into a managed logging platform, a security data lake, backups, exports and analysts' laptops.

For teams operating in Saudi Arabia and the UAE, define what each event must prove before writing the log statement. Remove secrets in the application, use indirect identifiers, and give every log class a documented routing and deletion policy.

This is practical engineering information, not legal advice. Sector rules and free-zone regimes can change the answer for a specific system.

The two laws point to the same engineering problem

Saudi Arabia's Personal Data Protection Law applies to personal-data processing conducted in the Kingdom and also to processing outside the Kingdom concerning individuals who reside there. SDAIA's current guidance describes purpose limitation, data minimisation, protection measures and destruction once the collection purpose has been fulfilled. The authority's National Data Governance Platform knowledge centre brings the amended law, implementing regulations and transfer rules into one compliance guide.

The UAE's federal Personal Data Protection Law is active and came into force on 2 January 2022. Article 5 requires personal data to be collected for a specific purpose, limited to what is necessary, secured and not kept after that purpose is exhausted unless it has been anonymised. Article 7 also requires controllers to document processing periods, access, erasure mechanisms, cross-border movement and security measures.

There are important boundaries. The UAE federal law excludes government data, government entities, security and judicial authorities, and personal health, banking and credit data covered by other legislation. It also excludes free-zone companies subject to their own data-protection laws. A bank or healthcare provider may still fall under the federal law for employee, marketing or other personal data outside a sector-specific exclusion. A company in DIFC or ADGM has a separate regime. The UAE Government's overview points to several of those laws.

Neither law gives ordinary application logs a universal retention period, so organisations must justify each log class against its purpose and any sector, contractual, litigation or security requirement. This is separate from statutory compliance records: Article 33 of Saudi Arabia's implementing regulations requires a controller's record of processing activities to be kept while processing continues and for five years after that activity ends. "Keep every application event for a year" is not a policy unless someone can explain why each field is needed for that year.

Start with an event contract, not a logging library

A useful application event records the time, service, initiator, attempted action and outcome. OWASP's Logging Cheat Sheet calls the broader model "when, where, who and what." It also recommends interaction identifiers so related events can be correlated.

OpenTelemetry's stable logs data model gives teams a vendor-neutral shape for that contract. It defines timestamps, severity, event name, resource information, attributes, and optional trace and span identifiers. Adopting that shape does not make a log private, but it reduces the temptation to dump an entire object into a free-text message.

A payment failure event that maps to OpenTelemetry might look like this:

{
  "Timestamp": "2026-08-15T12:04:33.218Z",
  "EventName": "checkout.payment_failed",
  "SeverityText": "WARN",
  "TraceId": "9f3c...a21d",
  "Attributes": {
    "actor.ref": "usr_hmac_8b72...",
    "market": "SA",
    "payment.provider": "provider_a",
    "result": "declined",
    "reason.code": "do_not_honor"
  }
}

The trace ID is abbreviated for display. The record does not need the customer's name, email, full IP address, card number, request body or provider response. Engineers can still connect it to a trace, measure failures by market and provider, and investigate the reason code. Because the stable actor reference and trace can still be linked to a person, this remains pseudonymised personal data rather than anonymous data.

Define fields through a schema registry or typed event wrapper, with an owner, purpose, classification and retention class attached to each field. Production systems should drop unknown attributes at source. If a quarantine path is unavoidable, redact before ingestion, restrict and encrypt the stream, and give it a short time to live.

Redact before the event leaves the process

Removing sensitive fields at the central collector is too late. The raw record may already exist in a container's stdout buffer, sidecar queue, host journal or retry payload.

Redaction should happen in the application or telemetry SDK before serialization. Use an allow-list for production fields. A deny-list is a backstop because teams will eventually introduce a field such as authorizationHeader or customerDocument that the old regex does not recognise.

OWASP says access tokens, session identifiers, passwords, connection strings, encryption keys, government identifiers, health data, bank account details and payment-card data should usually be removed, masked, hashed or encrypted rather than recorded directly. This is also an operational rule: a secret in a searchable log is a secret copied into every account and tool that can read that log.

Pseudonymisation helps when investigators need stable correlation. Generate actor_ref with a keyed HMAC over the internal user ID and keep the key outside the logging platform. A plain hash is weak when the input space is predictable. Rotate the key on a planned schedule and document whether older references must remain joinable.

Do not confuse pseudonymisation with anonymisation. The UAE law defines pseudonymised data as data that can be linked back using separately kept information, so it remains personal data. Its definition of anonymisation requires that a person cannot be identified or linked by any means. Teams using a practical re-identification risk test should not present that test as the statutory definition.

Architecture visual: SultanByte. Legal anchors: SDAIA Personal Data Protection Law guidance and UAE Federal Decree-Law No. 45 of 2021, checked 15 August 2026. Engineering guidance: OWASP Logging Cheat Sheet and OpenTelemetry Logs Data Model.

Route by market and purpose

A single global stream is convenient until teams must answer where Saudi customer events were processed, which vendor could access them, or how one person's records can be found and erased.

Keep the business market separate from a policy_domain derived from assessed tenant and account data. Residence, processing location, sector rules and free-zone status cannot be inferred from a checkout country code or request header. Route events into separate storage and access policies where the legal nexus, contracts or risk justify it. Keep routing failures observable without copying the rejected payload.

Cross-border transfer is not the same as public exposure. It is still processing. The UAE law sets conditions for transfer where an adequate protection level exists and exceptions where it does not. Saudi Arabia publishes a separate regulation for transfers outside the Kingdom. Assess each route against Saudi PDPL Article 29 and its transfer regulation, or UAE Articles 22 and 23, including purpose, adequacy or safeguards and any required risk assessment or exemption. Before using a regional or global SaaS platform, document where records and backups will live and which subprocessors or support teams can reach them. Then verify key control, deletion behaviour and the transfer mechanism.

Local storage alone does not solve the problem. A Saudi region administered by a global support team can still involve access from outside the country. A locally hosted cluster with shared credentials may be less defensible than a properly contracted service with strong access controls. Residency cannot substitute for controls on access, purpose, retention and transfers.

Separate security evidence from debug noise

Security events and debug records should not share one retention setting.

Authentication attempts, privilege changes, consent changes, exports, administrative reads and deletion actions often need durable audit evidence. Debug traces are verbose, contain unpredictable application values and lose value quickly. Keep production debug logging off by default, enable it for a narrow service and time window, and make the change itself an audited event.

One starting taxonomy has four classes:

The periods must come from the organisation's legal and operational analysis, not this example. Put the owner and deletion job beside each period. Include hot storage, archives and temporary exports in the schedule. For immutable backups, document expiry and stop deleted records from silently returning to production after a restore.

OWASP recommends tamper detection, restricted and reviewed read access, monitoring of log access, secure transport and due diligence before sending records to third parties. NIST's final SP 800-92, published in September 2006, provides guidance for developing, implementing and maintaining log-management practices. It remains useful operational guidance, but teams should account for newer cloud and telemetry architectures when applying it.

Payments teams have another overlay. The PCI Security Standards Council published PCI DSS v4.0.1 on 11 June 2024; it became the only active supported version after v4.0 retired on 31 December 2024. Cardholder environments need their logging design reviewed against PCI DSS as well as the applicable privacy law. Do not use a privacy-focused redaction policy to remove required audit evidence, and never retain sensitive authentication data to make an audit trail look complete.

Test the failure paths

Because logs support incident response and compliance evidence, test them as rigorously as the features they observe.

Test that secrets and direct identifiers never appear in emitted records, including exceptions and malformed requests. Feed the logger newline characters and structured payloads to check for log injection. Simulate a full disk, unavailable collector, expired certificate and rejected schema. Decide in advance whether loss of a logging sink fails open or closed. An unavailable debug sink, for example, should not automatically block customer transactions.

Then test deletion. Pick an event ID, follow it through hot storage, archive and export, and prove that each copy expires as designed. Verify the backup-expiry policy and restoration controls separately. Record privileged searches and exports. Alerts should catch disabled pipelines, sudden volume growth, schema rejection and access from an unexpected country or role.

The UAE law requires controllers and processors to use measures suited to processing risks and calls for regular testing of those measures. Saudi guidance likewise calls for organisational, administrative and technical protection. Redaction unit tests cover the application boundary. Production evidence must also show that routing, access controls and deletion work as documented.

A release gate teams can use

Before a new event reaches production, require five answers:

1. What operational or security decision will this event support?
2. Which fields are required for that decision, and which were removed?
3. Does any identifier permit direct or indirect identification?
4. Where will the event and its copies be processed, who can access them, and under which transfer arrangement?
5. What deletes every copy, and how has deletion been tested?

Block the release if the owner cannot answer them. Treat every log event as part of the product's data model. Aim for the smallest record that still lets an authorised team reconstruct what happened; anything more risks becoming a second customer database.

Cover visual: original artwork by SultanByte.