Client data processing.

Two different relationships

It is worth separating them, because they are often confused:

• Your enquiry to me — your name, your email, what you told me about the project. I decide what happens to that, so I am the controller. It is covered by the privacy policy.
• The data inside a system I build for you — your customers, your staff, your records. You decide what happens to it. I act on your instructions, which makes me a processor acting for you, and it is never mine to use.

What I will not do with it

Your data is not used for anything except delivering and supporting your system. It is not mined, not used to train anything, not used to build a product, not shared with another client, and not retained after our arrangement ends beyond what you ask for.

What I can see, and when

Building a system means administrative access to it. I am straight about the consequences: during development and during any support we agree, I can generally see what is in the database.

Where the data is sensitive, that access should be constrained rather than assumed, and it is a scoping decision made before the build rather than a conversation after it. Depending on what the system holds, that can mean developing against realistic synthetic data instead of live records, encrypting particular fields, keeping my access time-limited and logged, or handing production credentials to your own staff at go-live so I hold none. The Mosque Directory demo runs on sample data for exactly this reason.

Subprocessors

Any system has infrastructure underneath it, and whoever runs that infrastructure can technically reach the data. For your project those are named individually in the quotation before the build begins, with what each one costs, because you are entitled to know who is in the chain before you commit rather than to discover it later.

They are chosen for your constraints. If your organisation cannot have data leave the Maldives, or cannot use a particular vendor, that is a requirement to state at the start: it shapes the architecture, and it is expensive to retrofit.

Security, in proportion

• Enforced on the server. Who may see and change what is checked server-side, not hidden in the interface. An admin screen that is merely not linked is not a permission system.
• Roles separated where the organisation has real roles, so an account has the access its job needs and no more.
• Encrypted in transit always; at rest according to what the system holds.
• Credentials transferred securely at handover, and never by email or chat message.
• Audit trails where records are official or contested, so there is an answer to who changed what.

If something goes wrong

If I become aware of a breach affecting your data, I will tell you without delay and in any case within 72 hours of becoming aware, with what I know: what happened, what was affected, and what I am doing. You are the one who has to decide about notifying regulators and the people affected, and you cannot make that decision from information I have not given you.

Handover, and afterwards

On final payment you receive the source code and repository, the administrative accounts, hosting and domain access, DNS, credentials and documentation. From that point the system and everything in it is under your control.

Where I keep running something for you, the access needed to do that continues and is written down. Where I do not, my access should end, and you are entitled to ask me to confirm in writing that it has and that any working copies have been destroyed. Ask — a sentence confirming it is not a burden.

Putting it in the contract

This page describes how I work. It is not a substitute for a data processing agreement, and if your organisation needs one — institutional buyers usually do — say so during scoping and it forms part of the project agreement rather than an afterthought. I am not going to pretend a page on my own website is the same thing as a signed contract.