atiUjjwal

Data Security Policy

Last updated: 2026

Scope

This describes the security practices applied to systems I build and operate. Where a client contract sets stricter requirements, the contract takes precedence.

Encryption

Access control

Every system is role-based: a receptionist, a doctor, a teacher and an administrator see different data and can take different actions. Administrative access is granted to named individuals, not shared accounts. My own access to a client's production environment is limited to what support requires, and can be revoked by the client at any time.

Isolation

Multi-tenant platforms scope every query to the tenant. A school cannot read another school's records; a hospital cannot read another hospital's. This is enforced at the data layer, not only in the interface.

Third parties

Subprocessors are limited to hosting, database and, where required, payment or messaging providers. No client data is sent to analytics, advertising or machine-learning services. Any new subprocessor is disclosed before it is introduced.

Backups and recovery

Production databases are backed up on a regular schedule with point-in-time recovery where the provider supports it. Restores are tested rather than assumed.

Reporting a problem

If you believe you have found a vulnerability in something I built, contact me through any channel listed on this site. Reports are taken seriously, acknowledged quickly, and handled without legal threat to anyone reporting in good faith.

Honest limits

This page describes standard practice, not a certification. If your organisation needs formal compliance evidence, a named hosting region, a signed data processing agreement or a defined retention schedule, those are scoped and agreed per project — ask and you will get a straight answer rather than a badge.