Security
Security considered throughout the system lifecycle.
Security requirements depend on the system, data, users, integrations and operating environment. Kerah brings those decisions into discovery, architecture, implementation, launch and continued operation rather than treating them as a final checklist.
What gets decided, and when
Each area below is raised in discovery and revisited as the architecture settles. The decisions listed are the ones that are cheap to make early and expensive to retrofit.
Identity and access design
Access design starts with the roles the organization actually uses, not the roles a framework provides by default. Kerah designs the permission model alongside the workflow, so authority in the system matches authority in the organization.
Decisions this forces
- Which roles exist, and what each may see and change
- How least privilege is expressed for shared and delegated work
- How access is granted, reviewed and revoked as people change roles
- Whether integration with your existing identity provider is required
Environment and data separation
Kerah designs the separation between development, test and production environments for the engagement, and agrees what data each may hold. The default position is that production data does not flow into development.
Decisions this forces
- Which environments the engagement requires
- Whether any production data may be used for testing, and if so how it is reduced or masked
- How promotion between environments is controlled and recorded
- Where the boundary sits between Kerah's tooling and your infrastructure
Secrets and configuration
Credentials, keys and connection strings are treated as managed configuration rather than code. Kerah agrees where secrets live, who can read them and how they are rotated before implementation begins.
Decisions this forces
- Which secret store the engagement will use
- Who holds break-glass access, and how its use is recorded
- Rotation expectations for each class of credential
- How secrets are kept out of source control, documents and messaging
Encryption
Encryption requirements are defined against the data classification agreed in discovery — in transit as standard, and at rest according to the sensitivity of the data and the platform in use.
Decisions this forces
- The classification of each data set the system will hold
- Encryption requirements implied by that classification
- Key ownership and management responsibilities
- Any requirement that follows from your own policy or a regulator's
Logging and auditability
Kerah designs audit logging around the questions the organization will need to answer later: who changed a record, who approved a decision, and what the system knew at the time.
Decisions this forces
- Which events must be recorded, and in what detail
- How long audit records are retained
- Who may read audit data, and whether it can be altered
- How personal data in logs is minimised
Dependency and vulnerability management
Software dependencies age. Kerah agrees how updates and vulnerability response are handled during delivery, and — where a managed arrangement exists — after launch.
Decisions this forces
- How dependencies are reviewed and updated during delivery
- Who is responsible for vulnerability response after handover
- What severity triggers an out-of-cycle release
- How the position is reported to you
Backup and recovery
Backup design is only useful when restoration has been tested. Kerah defines the recovery expectations with you and includes a restore test rather than assuming the backup works.
Decisions this forces
- Acceptable data loss and acceptable downtime, stated explicitly
- Backup scope, frequency and retention
- Who performs a restore, and how it is verified
- How often a restore test is repeated
Monitoring and incident readiness
Kerah designs monitoring around failures that matter operationally, and agrees the response path before launch rather than during an incident.
Decisions this forces
- Which failures warrant an alert, and which are noise
- Who receives an alert, and what they are expected to do
- How an incident is recorded, communicated and reviewed
- What the rollback path is, and who may invoke it
Data inventory, retention and deletion
Kerah produces a data inventory for the systems it builds: what is held, why, on what basis, for how long, and how it is deleted. Retention that has never been written down is retention nobody can defend.
Decisions this forces
- What personal data the system holds and why it is necessary
- Retention periods per data category
- How deletion requests are executed, including in backups
- Where data resides, and whether that must be constrained
Suppliers and AI services
Any third-party service in the architecture is a supplier decision as well as a technical one. Kerah identifies what data each would receive and raises the contractual questions before integration, not after.
Decisions this forces
- Which third-party services the architecture requires
- What data each would receive, and whether that is permitted
- Whether a data processing agreement is required
- For AI services: whether inputs may be retained or used for training, and the fallback if the service is withdrawn
Data residency and regional constraint
Where data must remain is an architectural decision, not a hosting preference, and it applies to far more than the primary database. Kerah establishes the constraint in discovery and designs the whole architecture to hold it — including the parts that quietly leave a region by default.
Decisions this forces
- Which region the engagement requires, and which categories of data that covers
- Whether every service in the architecture is actually available in that region, not only the platform
- Whether logs, backups, support tickets, exports and AI prompts are in scope of the constraint — they usually are
- Whether automatic failover outside the region must be disabled, and what happens instead
Tenant separation between clients
Kerah maintains one product engineering line, but a client's production environment is designed to stand alone rather than to share infrastructure with another client's. Where a shared component would be simpler, the separation is stated explicitly rather than assumed.
Decisions this forces
- Whether the engagement requires its own cloud account or subscription
- Which resources are separate by design: database, storage, keys, knowledge base, audit log, backup vault, identity
- Whether any cross-client reporting or aggregation is permitted — the default is that none is
- Who administers the environment, and whether Kerah retains standing access after handover
Documentation available within an engagement
Within a contracted engagement Kerah can provide architecture and data-flow documentation, the access and permission model, the data inventory, and completed responses to your own security questionnaire.
Decisions this forces
- Which documents your assessment process requires
- What may be shared before a confidentiality agreement is in place
- Who on your side reviews and signs off
- How documentation is kept current as the system changes
Working with your security team
Kerah expects to be assessed. Within a contracted engagement — or under a confidentiality agreement beforehand — we complete vendor security questionnaires, sign data processing and security schedules, and provide the documentation your reviewers need.
Security contact: security@kerah.ae
Start a conversationDocumentation available within an engagement
- Architecture and data-flow documentation
- Access and permission model
- Data inventory with classification and retention
- Environment and deployment description
- Completed responses to your own security questionnaire
- Incident and escalation process for the delivered system
Reporting a vulnerability
If you believe you have found a vulnerability in this website, email security@kerah.ae with enough detail to reproduce it. We will acknowledge your report within five business days and keep you informed.
Reporting a weakness does not authorise you to test for one. Unless Kerah has authorised you in writing — naming the asset, the methods and the period — please report only what you noticed through ordinary use of this site. Infrastructure run by our hosting and delivery providers, and any system built for a client, are never in scope.
Please do not access, modify or remove data belonging to others. Publishing a finding needs a separate written agreement with us about timing and content; time passing on its own does not make it permissible.
Kerah will not bring a contractual or civil claim against a researcher who stays within those limits and acts in good faith. That is a commitment about what Kerah will do, and it is all Kerah can promise — it is not immunity from the criminal law, and it does not bind the police, a regulator, a client or our providers. Nothing here restricts you from reporting to the authorities or to your own legal adviser.
Security questions before a conversation?
Ask them early. It is a better use of both sides' time than discovering a constraint after a proposal.