Core privacy principlesمبادئ الخصوصية الأساسية

Privacy principles are the rules governing what a company may collect about you, why, how long it keeps it, and who it hands it to. They look much the same across most of the world, whatever the local law is called.

Modern privacy principles began decades before smartphones and cloud computing.

Why do I need privacy rules at all? I don't sell anyone's data

This is the first objection, and it is usually sincere. The company intends no harm and collects data only to improve the service. So where is the damage?

The damage does not come from your intent. It comes from accumulation.

Picture an instalment app. It knows your name, ID number and mobile. It knows everything you bought, where and when. From your repayment dates it knows when your salary lands. From the location of each transaction it knows where you live, where you work and when you travel. From analysing your purchases it may infer your health or your family situation.

The company collected none of that deliberately. Every field was gathered for a good reason at the time. But the sum of them is a file that knows more about you than the people closest to you do.

Now ask: what happens to that file if it leaks? If the company sells its assets? If an employee uses it to track an ex-spouse? If management decides three years from now to sell it to an insurer?

Privacy rules are not protection from evil companies. They are protection from the accumulation that happens inside well-meaning ones. Which is where the six principles you are about to read come from: all of them circle one idea, which is collect less, keep it for less time, and be able to explain why.

Rules older than the apps

In 1980, the OECD published guidelines on privacy and cross-border data flows. They did not mention cookies or facial recognition. They still described problems visible when a bank holds your salary, a budgeting app analyses spending, or a retailer sends your number to an advertiser.

Laws have since changed names and added detail, while their structure has remained recognisable. They require a reason and limit for collection, a retention period, protection, and evidence of delivery. These ideas let you make sense of a new law before memorising its article numbers.

Data begins with a person

Personal data (البيانات الشخصية) is information relating to an identified or identifiable person. A name and national identity number are direct examples. A device identifier, location trail, and purchase history are indirect examples because they can single someone out when combined with other information.

Removing a name does not automatically make data anonymous. A lending app might replace the name with an internal number while keeping the key that reconnects that number to its owner in another table. Pseudonymisation reduces exposure, but the information remains personal data because reconnection is possible.

Purpose draws the boundary

Purpose limitation means deciding why data is needed before collecting it. If a transfer company asks for a customer's address to complete a regulatory check, it cannot quietly reuse that address for property marketing. If a support team records a call to resolve a dispute, the recording does not automatically become training material for a voice model.

A phrase such as improving our services cannot carry every possible use. A useful purpose is specific enough for an engineer to know which use belongs inside it and which one needs another decision. It also helps the compliance team select a lawful basis (الأساس النظامي), retention period, and permitted audience.

Collect the least that performs the job

Data minimisation means not collecting a field merely because it is easy to obtain or might be useful one day. A bill-splitting app needs a payment amount and the identities of both parties. It does not need your entire contact list when you could type a friend's number. A lender needs information that measures repayment capacity, not the personal photographs stored on a phone.

This principle appears in product design, not only in a privacy notice. Make a field optional if the service works without it. Read only the necessary accounts through an open banking interface instead of requesting everything the interface permits. Give your team the result of an identity check when it does not need a copy of the identity document.

Minimisation cuts three costs at once: harm after a breach, work when answering a data request, and complexity when changing suppliers. Data you never collected does not need encryption, deletion, or an explanation to a regulator.

Data decays and expires

Accuracy requires data to be correct and current enough for its use. An old address in a marketing list is irritating. The same error in a sanctions check or credit decision can produce a wrongful rejection with a direct financial effect.

Accuracy does not require every field to be checked every day. The care required follows the effect of an error and how quickly the information changes. A phone number needs a route for updating it. An automated decision needs a known source and date. A successful challenge needs to correct the source and the copies derived from it.

Storage limitation means not keeping data forever just in case. Each category needs an expiry date or event. Account closure followed by the end of a statutory retention period is one example. An accounting record, call recording, identity copy, and abandoned application can each have a different period.

A retention schedule achieves little if copies remain indefinitely in the analytics warehouse, logs, backups, and supplier systems. Deletion rules must reach dependent systems and vendors. A backup might remain until its normal replacement cycle under restricted access. Its deletion rule must apply again after restoration.

Security follows the risk

The principle of integrity and confidentiality requires protection against unauthorised access, alteration, and loss. No single tool achieves it. Encryption protects a channel or file, access controls decide who can open it, audit logs reveal what they did, and backups recover data after damage.

Suitable protection depends on the data and the likely harm. Full card details, biometrics, and medical results demand stricter controls than a company's published email address. Sensitivity is not the whole risk. A large history of ordinary transactions can expose a person's life even when each record appears harmless alone.

Security starts by limiting access. A support employee sees what is needed for the case. A product analyst works with reduced or aggregated data. A vendor receives only the scope required by its contract. Access is reviewed when an employee changes role or a vendor's work ends, not after an incident.

Accountability makes principles provable

Accountability means being able to demonstrate privacy rather than merely claiming it. You keep a record of the data, purposes, lawful bases, retention periods, suppliers, controls, and decisions. If a regulator asks why a product collects precise location, the answer cannot be that a developer added it two years ago.

Accountability gives every principle an owner and a repeated activity. A product manager reviews fields before launch. An engineer implements deletion and permissions. The security team tests protection. The privacy lead checks that reasons and periods are documented. Having a privacy team does not remove responsibility from everyone making the underlying decisions.

A lawful basis is not a consent button

A lawful basis answers a different question from purpose. Purpose explains what you intend to do. The basis explains why the law permits it. Processing may be necessary for a customer contract, legal duty, or vital interest. It may instead rely on a public task, a balanced legitimate interest, or consent.

The exact list differs between countries, but the need for a valid reason recurs. A bank does not need renewed consent every morning to show the balance of the account you asked it to open. A transfer company may retain a record because anti-money-laundering law requires it, even if the customer asks for deletion the next day.

Consent is often the weakest basis, not the strongest. It fails when hidden, bundled with other purposes, or made a condition of a service that does not need it. The person can withdraw it, after which processing built on consent must stop unless another basis genuinely applied from the start.

You cannot switch bases after an objection to rescue a poor decision. If marketing was described as consensual and the customer withdraws, it cannot suddenly be renamed a legitimate interest. The basis is selected while designing the processing, documented, and explained to the person. It is not invented when a complaint arrives.

One test for any feature

Before launching a financial feature, write down the data it takes, the purpose of each field, and the basis that permits it. Remove what is unnecessary. Set the source for corrections, deletion date, permitted users, and protection. Finally, retain evidence that these decisions were made and implemented.