Isolation, encryption and accountability are properties of the deployment itself — not controls layered on afterwards. Every customer receives a dedicated instance: in your own infrastructure, or on Wekalp's hosted cloud. The control set is the same either way.
Separation between customers is not a tenant identifier that application logic must check correctly every time. There is no shared layer left to misconfigure.
What can reach the platform from outside, and what a stolen credential is worth. Both are answered by how the system is built rather than by policy.
Logs are written to a segregated, append-only store outside the platform's write path. An actor operating within the application cannot erase evidence of their own activity.
A dedicated on-premises instance in your own private cloud or data centre, or Wekalp's hosted cloud — where single-tenant is the default, not an upgrade.
Multi-tenancy is the common default: one platform serving many customers, separated by a tenant identifier inside a shared database. Wekalp does not work that way. Every customer receives a dedicated deployment with its own compute, storage and metadata store.
A tenant ID that application logic must check correctly, every time. One missed check is a cross-customer exposure.
There is no shared layer left to misconfigure. No common data plane, no shared query engine, no tenant-ID database.
Dedicated compute, dedicated storage, dedicated metadata store — per customer. No ingestion, storage or serving tier is shared.
All platform workloads run inside private subnets with tightly restricted ingress. The platform cannot be reached, scanned or probed directly from outside.
Authentication runs on a dedicated, industry-standard IAM layer federated to your identity provider — not authentication logic written into the application.
Access is granted through roles rather than to individuals. Permissions are granular to three levels — schema, table and column — and a new role starts with nothing, granted only what it demonstrably needs.
| record_id | region | category | amount | customer_name | tax_id |
|---|---|---|---|---|---|
| R-100241 | NORTH | STANDARD | 1,204,880 | • • • • • • | • • • • • • |
| R-100242 | CENTRAL | PREMIUM | 840,000 | • • • • • • | • • • • • • |
| R-100243 | SOUTH | STANDARD | 296,415 | • • • • • • | • • • • • • |
Permissions attach to a role. People join and leave roles; the permission set stays reviewable as one object. Nothing attached to a named user survives their move to another team.
A role can be permitted a table but denied fields inside it — PII stays out of reach. One governed dataset serves several audiences, with no second, redacted copy to build and protect.
A new role starts with nothing and is granted only what it demonstrably needs. Permissions are reviewed as a set rather than reconstructed user by user.
Encryption is applied uniformly rather than selectively — the same standard on the wire between two internal services as on the link from your browser, and the same standard on a backup copy as on the primary database.
Every hop is TLS 1.2 or above — including links that never leave the deployment. Certificates are issued, monitored and renewed automatically on schedule, so an expiring certificate cannot become an outage and nobody handles a private key by hand to prevent one.
Files, extracts and landed data — AES-256 at rest.
Tables, metadata and configuration — AES-256 at rest.
The same protection as primary, so a restored or relocated copy is never the weak link.
Personally identifiable fields receive an additional layer beyond storage-level encryption. Envelope encryption is applied per dataset: each dataset holds its own data encryption key, so exposure of one key cannot compromise another.
Data keys are stored only as ciphertext — never in plaintext, never inside application code, configuration or environment variables. Key access is restricted to a narrowly scoped role, not the application's database credentials. Possession of the data does not confer the ability to read it.
The managed key service sits in a separate trust boundary from the data itself. Reaching the database does not reach the keys.
Master keys rotate on a defined schedule. Data keys rotate on trigger events — personnel change, suspected compromise.
Destroying a key renders that dataset's sensitive fields unrecoverable — including in every backup holding them. Erasure obligations are met by one verifiable key operation rather than by hunting copies.
Every route by which data can leave the platform is governed — and each one leaves a record naming who took what, and when.
Permission-gated by role, and recorded in the activity log — who exported what, and when.
Scoped per role. A token can retrieve only what its role is permitted to see, and only for a limited window.
Data is shared by granting access inside the platform rather than by circulating attachments, so distribution stays visible and revocable.
| user | timestamp | source_ip | object | action |
|---|---|---|---|---|
| a.moreau | 2026-03-14 09:41 | 10.44.12.7 | CUSTOMER_MASTER | EXPORT · CSV |
Every access and every administrative action is recorded — and recorded where the system that produced it cannot alter it. A log an attacker can edit is not evidence; it is a formality.
…and anyone operating within it
Applications and operators produce log entries in the ordinary course of running the system. That is the extent of their relationship with the record.
Append-only · segregated · SIEM-exportable
Held outside the platform's write path, so an actor operating within the application cannot erase evidence of their own activity.
Acting user, timestamp, source IP address and object accessed — enough granularity to reconstruct who touched which dataset and when.
Designated security operations roles only — not end users, and not platform operators.
Retention is configurable to your own policy and obligations, not fixed by ours. Logs ship to your own SIEM and correlate with the rest of your estate.
A control set is a claim until somebody independent tries to break it. The web application and its APIs have undergone vulnerability assessment and penetration testing by a CERT-In empanelled auditor.
Coverage spans OWASP Top 10 classes — injection, broken access control, authentication weaknesses, misconfiguration and related classes. Findings were remediated and retested to confirm closure, and assessment is repeated on a defined cadence and after any significant platform change.
An application can be sound while the environment around it is not. Cloud infrastructure is assessed on its own terms.
Container images and dependencies are scanned before release, and a defined patch cadence governs newly disclosed vulnerabilities.
Resilience is measured, not asserted. Two numbers describe it: how much data a failure can cost you, and how long you wait to work again.
The maximum window of data a failure can cost you.
The maximum time before the platform is serving again.
Restore to a chosen moment, not only the last full snapshot — limiting loss from accidental deletion or corruption.
Backups are encrypted and stored geographically separate from primary systems. Prior versions of data files are preserved through object versioning.
Infrastructure is defined as code, so the platform can be rebuilt reproducibly rather than reassembled by hand.
We run and operate it. Single-tenant is the default — not an enterprise upgrade, and not something you have to ask for. Your deployment has its own compute, storage and metadata store from day one.
Deployed in your own private cloud or data centre, under your controls, inside your perimeter. For teams with data-residency obligations or an internal requirement that the data plane never leaves their estate.
The architecture, the encryption and the audit trail do not change with the address. Only who runs it does.
Most of what a security questionnaire asks for is below. If yours asks for more — and it usually does — send it over.
| Domain | Control | How it works |
|---|---|---|
| Tenancy | Single-tenant deployment | Dedicated compute, storage and metadata store per customer. No shared data plane, no shared query engine, no tenant-ID database. |
| Hosting | On-premises or Wekalp-hosted | A dedicated instance in your own private cloud or data centre, or Wekalp's hosted cloud. Same control set either way. |
| Network | Private subnets, restricted ingress | No data-plane endpoint exposed to the public internet. The platform cannot be reached, scanned or probed directly from outside. |
| API access | OAuth 2.0 + OpenID Connect | Tokens scoped to a role, short-lived and revocable. Credentials stored only as irreversible hashes. |
| Identity | Federated SSO via OIDC / SAML | A dedicated IAM layer federated to your IdP. Joiners, movers and leavers stay in your directory — disable there and access ends here. |
| Authentication | MFA enforced | Enforced on federated and local accounts alike. Password complexity, expiry and reuse policies configurable to your standard. |
| Authorisation | RBAC to schema, table and column | Least privilege by default. Restricted fields are not returned at all — one governed dataset can serve several audiences without a redacted copy. |
| Encryption | TLS 1.2+ in transit | All external and internal service-to-service traffic. Certificates issued, monitored and renewed automatically. |
| Encryption | AES-256 at rest | Uniform across object storage, databases and backups. Backup copies carry the same protection as primary data. |
| PII | Field-level envelope encryption | A data encryption key per dataset, wrapped by a master key in a managed key service outside the data's trust boundary. |
| Key custody | Separate trust boundary, scoped role | Data keys stored only as ciphertext — never in application code, configuration or environment variables. Key destruction is a verifiable erasure mechanism. |
| Egress | Governed and recorded | Downloads, exports, API and in-platform sharing are each permission-gated by role, recorded in the activity log, and revocable. |
| Logging | Append-only, segregated store | User activity, system and administrative streams. The platform can write entries but cannot modify or delete them. |
| Log access | Security roles, your retention, your SIEM | Readable by designated security operations roles only. Retention configurable to your policy; exportable to your SIEM. |
| Assessment | CERT-In empanelled VAPT | Application and API testing across OWASP Top 10 classes; findings remediated and retested. Repeated on cadence and after significant change. |
| Assessment | Infrastructure assessed separately | Network configuration, identity and access policy, storage permissions and logging posture. |
| Secure delivery | Pipeline scanning, patch cadence | Container images and dependencies scanned before release; a defined patch cadence governs newly disclosed vulnerabilities. |
| Resilience | RPO ≤ 1 hour · RTO ≤ 8 hours | Design targets, confirmed and validated against your requirements at deployment. Point-in-time recovery, object versioning, infrastructure as code. |
| Backups | Encrypted, geo-separate | Stored geographically separate from primary systems, carrying the same AES-256 protection as primary data. |
Single-tenant. Every customer receives a dedicated deployment with its own compute, storage and metadata store. No ingestion, storage or serving tier is shared between customers; queries run on compute provisioned for you alone; and no shared table holds your records beside another organisation's, split by an identifier.
This matters because in a multi-tenant design, separation is a column value — a tenant ID that application logic must check correctly, every time. Here there is no shared layer left to misconfigure.
Yes. Wekalp can run as a dedicated on-premises instance in your own private cloud or data centre, under your controls. The alternative is Wekalp's hosted cloud, where single-tenant is the default rather than an upgrade. Both options carry the same control set.
No data-plane endpoint is. All platform workloads run inside private subnets with tightly restricted ingress, so the platform cannot be reached, scanned or probed directly from outside. Access arrives only through controlled, authenticated entry points.
Programmatic access uses OAuth 2.0 with OpenID Connect. Tokens are scoped to a role, short-lived and revocable, so an intercepted token grants only that role's permissions and only for a limited window.
Authentication is federated to your existing identity provider over OIDC or SAML and runs on a dedicated, industry-standard IAM layer — not authentication logic written into the application. User lifecycle stays where it already is: disable an account in your directory and access here ends.
Multi-factor authentication is enforced, including on local accounts. Where local accounts are used, password complexity, expiry and reuse policies are configurable to your standard.
Permissions are granular to three levels: schema, table and column. Access is granted through roles rather than to individuals, and a new role starts with nothing, granted only what it demonstrably needs.
Column-level control means one governed dataset can serve several audiences. An analyst can be permitted amounts, category and region on the same table from which their role is denied customer name and tax identifier — with no second, redacted copy to build and protect. Restricted fields are not returned at all, not merely hidden in the interface.
PII fields receive an additional layer of envelope encryption applied per dataset. Each dataset holds its own data encryption key, wrapped by a master key held in a managed key service that sits in a separate trust boundary from the data. Compromise of one key exposes one dataset — never the estate.
Data keys are stored only as ciphertext, never in application code, configuration or environment variables, and key access is restricted to a narrowly scoped role rather than the application's database credentials.
Yes. Because encrypted data is unreadable without its key, destroying a dataset's key renders that dataset's sensitive fields unrecoverable — including in every backup holding them. The obligation is met by one verifiable key operation rather than by hunting copies across primary systems and backup media.
No. Logs are held in a dedicated store segregated from the platform, outside its write path. The platform — and anyone operating within it — can write entries but cannot modify or delete them, so an actor operating within the application cannot erase evidence of their own activity.
Every entry carries acting user, timestamp, source IP address and object accessed. Logs are readable by designated security operations roles only, retained on your policy, and exportable to your own SIEM.
The web application and its APIs have undergone vulnerability assessment and penetration testing by a CERT-In empanelled auditor, covering OWASP Top 10 classes including injection, broken access control, authentication weaknesses and misconfiguration. Findings were remediated and retested to confirm closure.
Assessment is repeated on a defined cadence and after significant platform change, and cloud infrastructure is assessed separately from the application — covering network configuration, identity and access policy, storage permissions and logging posture.
Design targets are a Recovery Point Objective of one hour or less and a Recovery Time Objective of eight hours or less. Actual objectives are confirmed and validated against your requirements during deployment.
Backups are encrypted and stored geographically separate from primary systems, with point-in-time recovery to a chosen moment rather than only the last full snapshot, object versioning to preserve prior versions of data files, and infrastructure defined as code so the platform can be rebuilt reproducibly.
Every security review asks something this page does not cover. Send yours — we would rather answer it properly than have you infer it.