Trust Center
Evidence first. Then technology.
What a procurement, security or privacy reviewer needs in order to assess Kerah — including the things Kerah cannot yet evidence, stated plainly.
Data residency is architecture, not hosting.
A residency requirement that covers only the primary database is not a residency requirement. These commitments apply to a client platform Kerah delivers under contract.
- Client platforms are designed to hold customer, beneficiary, employee, partner, case, document, audit and backup data within the region agreed in the contract
- Production and disaster-recovery copies, database replicas, object storage, logs and support records carrying production data are all in scope of that commitment — not only the primary database
- AI prompts, responses, vector embeddings and evaluation traces are treated as in-scope data, because they routinely contain the record they were derived from
- Automatic failover outside the agreed region is disabled by default and requires a contract change, not an operational decision
- Every service in the architecture is verified as available in the agreed region before it is adopted — not only the primary platform
- Exports, handover copies and anything produced at exit are in scope of the same constraint, so a system does not leave the region on its way out of the engagement
One codebase. Separate systems.
Kerah maintains a single product engineering line, but each client's production environment is designed to stand alone: its own deployment, database, object storage, encryption keys, AI knowledge base, audit log, backup vault and identity configuration — preferably its own cloud account. There is no cross-client reporting and no cross-client model training.
- Its own application deployment
- Its own database and object storage
- Its own encryption keys
- Its own AI knowledge base and vector store
- Its own audit logs and backup vault
- Its own identity configuration
- Its own configuration, workflows and reporting
Accountable roles
Kerah publishes accountability by role. These are accountabilities rather than posts, and one person may hold more than one; the bid response names who holds each, with credentials and references, to the people carrying out the assessment. Team size is a matter for that response, not for this page.
- Chief architect
- Target architecture, integration design, data residency design, exit and portability design, and non-functional requirementsHolder named in the bid response.
- Security lead
- Threat modelling, access design, testing, incident response and the security scheduleHolder named in the bid response.
- Privacy lead
- Data inventories, impact assessments, records and retention schedules, the data processing agreement and data-subject rights support — and, on this website, executing the published retention schedule and answering rights requests
- Responsible AI lead
- AI register, evaluation sets, human-approval design, monitoring and model incident responseHolder named in the bid response.
- Domain lead
- Operating model, the client's business and regulatory rules, and the practice of the people who will use the systemHolder named in the bid response.
- Delivery lead
- Plan, acceptance, risk management, reporting and service transitionHolder named in the bid response.
Documentation on request
Provided within a procurement process or under a confidentiality agreement. Kerah does not publish its internal security documentation, and a supplier that does should be treated with caution.
How Kerah approaches security in delivery- Trade licence extract and company profile
- Authorised signatory information
- Architecture and data-flow documentation for the proposed solution
- Access and permission model
- Data inventory and processing description
- Records, retention, deletion and exit arrangements for the proposed solution
- Draft data processing agreement, security schedule and AI governance schedule
- Named role holders, with credentials and references
- Completed responses to the buyer's own security and privacy questionnaire
Reporting a vulnerability
If you believe you have found a security issue in this website or in a Kerah system, report it to security@kerah.ae. Please include enough detail to reproduce it, and give Kerah a reasonable opportunity to respond before disclosing publicly.
Reports are acknowledged within five business days.
Send us your security questionnaire.
Kerah would rather answer it before a proposal than after one.