CERTHIX / Data residency

Know where every part of your safety record goes.

Treat records, attachments, backups and logs as separate parts of the data footprint.
Set the location and access rules for each service before putting live records into it.
Include support and AI processing in the same assessment.

Data residency

Storage, processing and access locations

Structured records, such as incidents, inspections and risk assessments, are stored in PostgreSQL. Uploaded evidence follows a separate object-storage path.
A database region alone does not establish where attachments are stored. Both services need an explicit location and replication configuration.
Tenant isolation controls which organisation can access a record. It is a different control from the physical location of the service holding it.

The application’s Azure design identifies UAE North as its primary region. UAE Central is the proposed recovery location, subject to the required services and subscription access being available.
A regional design is not a promise that every service is deployed there. Database, storage, monitoring and any AI service must each be checked.
The repository currently documents a hosted demonstration stack. A customer production environment requires its own confirmed service and location configuration.

Backup location and replication settings can extend the data footprint beyond the primary database region. They belong in the deployment specification.
Recovery planning must cover attachment storage as well as database records, so restored records do not point to missing evidence.
Retention periods, deletion procedures and the time taken for deleted data to expire from backups must be documented for the chosen environment.

Remote support access may involve people outside the hosting region even when the stored data remains in-country. Authorised access and access location need separate controls.
Logs and monitoring services can create additional copies of identifiers or operational information. Keep their content, location and retention within the agreed policy.
Restrict support access to the required task and scope. Do not use a general production data copy for development or troubleshooting.

An AI request can create a separate processing path for prompts, retrieved records and generated output. Hosting the main database locally does not locate the model endpoint.
Before enabling an AI workflow, define the permitted data, model service, processing region and provider retention terms.
Sensitive records need explicit access boundaries. A language selection in the interface does not change data residency.

The deployment record should identify the primary database, evidence store, recovery copies, monitoring destination and any external processors.
Operational ownership should cover changes to locations, service configuration, support access and retention.
Residency is one part of privacy governance. Access controls and processing terms remain necessary even when all storage is in the same country.

Illustrative workflows

Map structured school records and uploaded evidence to their respective services.
Check recovery, monitoring and support arrangements against the same requirement.
Enable an AI workflow only after its separate processing path has been assessed.

Identify which records the service receives, not just where its website is hosted.
Review the processing location, retained copies and the people who can access them.
Update the deployment record before transferring production information.