Privacy by Design in Custom Software: The Decisions to Make Before the First Line of Code

Privacy by design means making data protection decisions while a system is still on paper, when they cost a conversation rather than a rebuild. In practice it comes down to eight decisions:

1. Collect less.
2. Record each field’s purpose and retention.
3. Keep identity apart from activity.
4. Encrypt where it changes the outcome.
5. Build deletion as a feature.
6. Keep personal data out of logs, test systems and analytics.
7. Design for access and portability requests.
8. Grant access by role, with a trail.

Europe’s GDPR requires this in terms, in Article 25. Oman’s Personal Data Protection Law never uses the phrase. But its duties make retrofitting expensive enough that designing for them first is the only sensible route. Since September 2026 those duties include erasure as soon as the purpose ends and controls on automated decisions.

This article is the engineering method. For the legal obligations it serves, read the seven things Oman’s PDPL changes inside your systems and what the September 2026 amendments added.

Why at design time

Personal data spreads. A field added in week three is copied into a reporting database by month two. By month six it has reached an analytics tool, a CSV export and a backup set. Every copy is a place you will later have to secure, disclose on request, and erase.

Deciding at design time is cheaper for a simple reason: there is only one copy to decide about.

The law makes the timing matter too. Oman’s Article 13 requires controllers to put controls in place covering the risks the processing creates, procedures for transferring data, and technical and procedural measures. A breach carries a fine of OMR 5,000 to 10,000. The Executive Regulation adds confidentiality controls: protection against unauthorised access, leakage and misuse, recovery systems for incidents, and testing of whether technical measures work. It also adds a record of processing activities that must describe, among other things, how data is erased. None of these can be produced honestly for a system whose design ignored them.

1. Collect less, on purpose

Every field on a form should be able to answer one question: what will we do with this? “It might be useful” is not an answer, and since September 2026 Oman’s law gives it no legal footing either.

Four habits help:

• Make fields optional unless the process genuinely needs them. A delivery needs an address; a newsletter does not.
• Do not copy identity documents by default. If you need to verify a civil number, store the result of the check, not a scan of the card.
• Avoid free-text fields where a choice will do. Free text is where people type medical conditions, family circumstances and complaints about named staff, which turns an ordinary table into a sensitive one.
• Ask for data when you need it, not up front. A customer’s date of birth may matter at the first warranty claim, not at sign-up.

2. Record each field’s purpose and retention in the schema

Treat personal data as something the system knows about, not something it happens to store. For every table and column holding personal data, record five things:

• its category;
• its purpose;
• its lawful basis;
• its retention rule;
• whether it is sensitive.

Keep that record alongside the schema, in the same repository, so it changes when the database changes.

That metadata then drives behaviour instead of documentation. Deletion jobs read the retention rules. Access rules read the sensitivity flags. Subject access exports read the categories. And when an auditor asks for your record of processing activities, much of it comes from the same source. A spreadsheet maintained beside the system is accurate for a week; metadata the system depends on stays accurate because things break when it is wrong.

3. Keep identity apart from activity

Most of what a business system does with personal data does not need to know who the person is. A sales report needs order values, dates and products. It does not need the customer’s name and phone number.

Pseudonymisation means storing identifying details in one place and referring to people everywhere else by an internal key. It reduces the damage of most incidents, because a leak of the activity tables does not reveal identities on its own. It makes analytics safer. And it makes deletion simpler: remove the identity record and the activity becomes much harder to link back.

Pseudonymised data is still personal data, because you hold the key. Anonymised data, where no one can identify the person by any means, is different. Oman’s Executive Regulation does not require consent to transfer data abroad once it has been made genuinely unidentifiable. That is a strong reason to anonymise analytics or AI-training sets before they leave the country — and a reason to be honest about whether the anonymisation really holds.

4. Encrypt where it changes the outcome

Encryption is often bought as a box to tick. Use it where it changes what an attacker can do:

• In transit, everywhere. TLS between users and the system, and between internal services too.
• At rest, for disks and backups. This protects against a lost laptop or a stolen backup. It does not protect against someone who logs in to the application with a valid account.
• Field-level encryption for the most sensitive values — health details, national identifiers, bank details. The application can then decrypt them only for the screens and roles that need them.
• Keys managed separately from the data, so a copy of the database is not also a copy of the keys.

Be clear about what each layer protects against. A system with encrypted disks and every administrator able to export the whole customer table has solved the wrong problem.

5. Build deletion as a feature

Since 7 September 2026, Oman’s law requires personal data to be erased immediately once the purpose of processing ends. It may be kept only for an existing dispute or a legal obligation. That turns deletion from an occasional clean-up into a core function.

Design it as one:

• Retention rules per category, read by scheduled jobs that delete or anonymise automatically.
• Cascades that follow the data into child tables, search indexes, caches and file storage.
• Legal holds that pause deletion for a specific record when a dispute or legal obligation applies, with the reason recorded.
• Backups that expire. You usually cannot edit a backup, but you can make sure backups age out on a defined cycle. Document that a deleted record will disappear from them within that cycle.
• An erasure log that records what was deleted, when and under which rule, without keeping the deleted data itself.

A system without these will eventually be asked to delete someone and find that it cannot, or cannot prove it did.

6. Keep personal data out of the places it leaks

The production database is usually the best-protected copy of personal data you have. The leaks happen elsewhere:

• Logs and error reports. Developers log request bodies to debug problems, and those bodies contain names, phone numbers and sometimes passwords. Mask personal fields before logging. OWASP’s logging guidance says the same.
• Test and staging environments. Copies of production data for testing are routine and risky. Use masked or synthetic data; where real data is unavoidable, restrict and log access, and delete the copy afterwards.
• Analytics and marketing tools. Send identifiers only where the purpose and consent cover it.
• Exports. Limit who can export, log exports, and prefer reports that do not carry raw personal data.
• Chatbot transcripts and AI prompts. Conversations collect whatever customers type, and prompts sent to external models leave your infrastructure. What your chatbot does with customer data covers this in detail.

7. Design for access and portability requests

Under Oman’s Executive Regulation, a data subject may ask for a copy of their data in a readable electronic or paper form. The controller must decide within 45 days, and the copy must not reveal other people’s data. GDPR requires a response within one month.

Build this as a function: one identifier in, one complete and structured record out, assembled from every system that holds personal data. If the metadata from decision 2 exists, most of the work is already done. Make the export machine-readable, because portability means another organisation can import it, not just read it.

8. Grant access by role, with a trail

Who can see which fields, and who saw what, is the other half of privacy by design. Oman’s record of processing activities must describe the people authorised to access personal data. Its 2026 Cybercrime Law also punishes exceeding authorised access, with heavier penalties when an employee does it in the course of work. Who can see what: access control and audit trails covers the design.

A design review in eight questions

Ask these of every feature that touches personal data, before it is built:

1. What personal data does it collect or use, and is each item necessary?
2. What is the purpose and lawful basis for each item?
3. How long is it kept, and what deletes it?
4. Who can see it, and is that access logged?
5. Where is it stored, copied and sent — including logs, backups, analytics and external APIs?
6. Does any of it leave Oman, and on what basis?
7. Does the feature make or apply decisions about people automatically, and can they object?
8. How would we produce, correct or delete one person’s data from it?

A feature that cannot answer these is not ready to build. A team that asks them routinely rarely needs a separate privacy project later.

---

Frequently asked questions

Is privacy by design a legal requirement in Oman? Oman’s law does not use the phrase. But it requires controls covering risks and technical measures (Article 13), confidentiality and recovery controls (Executive Regulation Article 26), proof of consent, and erasure when the purpose ends. Meeting those after the fact is far harder than designing for them. GDPR Article 25 requires data protection by design in terms.

Does encrypting the database make us compliant? No. Encryption at rest protects against stolen disks and backups, not against misuse through valid accounts. Compliance also needs purpose limitation, access control, logging, retention and erasure, and the ability to answer requests.

What is the difference between pseudonymised and anonymised data? Pseudonymised data replaces identifiers with keys you still hold, so it remains personal data. Anonymised data cannot be linked to a person by any means. Oman’s Executive Regulation does not require consent to transfer genuinely anonymised data abroad.

Can we use production data in our test environment? Avoid it. Use masked or synthetic data for development and testing. If real data is unavoidable, restrict access, log it, and delete the copy when testing ends.

How do we delete data from backups? Usually by letting backups expire on a defined rotation rather than editing them, and documenting that cycle. Combine that with legal holds for records under dispute or legal retention.

How long do we have to answer a request for a copy of someone’s data in Oman? The Executive Regulation requires the controller to decide on the request within 45 days of receiving it. The copy must be readable, electronic or paper, and must not include other people’s data.

---

This article states the position under Oman’s Personal Data Protection Law as amended by Royal Decree 68/2026, its Executive Regulation, and the GDPR, as in force on 21 October 2026, the date of publication. It is not legal advice; confirm your position with a qualified adviser.

Sources: Royal Decree 68/2026 amending the Personal Data Protection Law · Royal Decree 6/2022 — Personal Data Protection Law (Arabic text) · Ministerial Decision 34/2024 — Executive Regulation (Arabic text) · GDPR Article 25 (EUR-Lex) · EDPB — Guidelines 4/2019 on data protection by design and by default · OWASP — Logging Cheat Sheet

Starting a new system and want privacy designed in rather than bolted on? ZAWAT builds custom software with purpose tagging, retention, erasure and access control treated as part of the build. Book a call.