# Corporate travel platform security: architecture, sign-in and data privacy

Source: https://kurumsal.pro/en/security/ — Last updated: 2026-11-04

The Kurumsal.pro portal carries the staff, passport and payment data of your agency's corporate clients. Security is therefore built in layers: a separate database per tenant, a server layer that keeps keys out of the browser, two-factor authentication required by role, passkey sign-in, masked ID numbers and an immutable wallet ledger.

## In short
- Kurumsal.pro runs on a multi-tenant architecture, and the data of each tenant is kept in a separate database.
- The browser does not connect to the backend directly; requests pass through the portal server, and service keys and session keys never reach the browser.
- Sign-in uses email and password, two-factor authentication with an authenticator app (TOTP) and passkeys; two-factor authentication is required by default for the company administrator, finance and approver roles.
- With default settings, 5 wrong password attempts lock the account for 15 minutes, and all sessions are closed when the password changes.
- Supplier, net price, markup and profit information is removed from portal responses, ID numbers are shown only masked and card details are not stored.

When a corporate client decides to use a travel portal, one of the first questions is security: where is the passport and ID information of staff kept, who can see it, and what happens if an account is taken over? Kurumsal.pro, running on DIJI.TECH infrastructure, answers these questions across architecture, sign-in, authorisation and data privacy in the portal that opens under your agency's brand. On this page you will find a technical outline you can pass on to the information security team of your corporate client.

## What layers make up corporate travel platform security?

Security in Kurumsal.pro is handled in five layers: **architecture** (where data is kept and what reaches the browser), **authentication** (who signs in and how), **authorisation** (what a person can see after signing in), **data privacy** (which fields are never shown to whom) and **traceability** (who made which decision). The sections below go through these layers in order, with their default values.

## How does the architecture separate data?

Kurumsal.pro runs on a multi-tenant architecture and **the data of each tenant is kept in a separate database**. The records of companies, branches, departments and staff sit in the tenant's own database. The shared (global) database holds information shared across tenants, such as the domain mapping, the list of portal sites and platform catalogues.

The portal is a separate web application and the browser does not connect to the backend directly. A request from the browser first reaches the portal's own server (BFF, backend for frontend) and is forwarded from there to the corporate portal API. The service key and the staff member's session key stay on this server and never reach the browser. Directory traversal attempts in the request path (for example `..` or an encoded separator) are rejected.

On every request the tenant is resolved from the domain name. The domain must be active and verified in the shared mapping; the portal does not open on an unverified domain. The domain header forwarded by a proxy is considered only when it comes from allowed server addresses. The access token of the corporate portal is produced by a separate issuer with a separate signing key, is short-lived (15 minutes by default) and is valid only in the corporate portal API. The session token of the agency panel is not accepted in the portal API.

## How do staff sign in to the portal?

There is no self-registration in the portal. The company or the agency creates the accounts; staff activate their account through the invitation link sent to their email (valid for 7 days by default). The work email used in the invitation must belong to one of the company's allowed domains. While opening the account, the person approves the KVKK privacy notice and sets a password.

Sign-in is strengthened in three ways:

- **Password rule:** at least 10 characters, with an uppercase letter, a lowercase letter and a digit required.
- **Two-factor authentication (TOTP):** an authenticator app is set up with a QR code or a manually entered key, and a 6-digit code is requested at sign-in. The code step is valid for 5 minutes and allows at most 5 attempts.
- **Passkey:** passwordless sign-in with fingerprint, face recognition or the device lock. Staff add, list and delete passkeys from the security tab of their profile.

With default settings, **the account is locked for 15 minutes after 5 wrong attempts**. Sign-in responses do not reveal whether an account exists for the email entered, so email addresses cannot be tried one by one to learn which accounts exist. Passkey sign-in goes through the same lockout and account status rules. The password reset link is valid for 60 minutes by default, and when the password is changed all open sessions of the person are closed. The last sign-in information is also visible on the security tab of the profile.

For a short definition, see the [two-factor authentication](/en/glossary/two-factor-authentication/) glossary entry.

## Who can make two-factor authentication mandatory?

Two-factor authentication is required by role. In a new company it is required by default for the **Company administrator, Finance and Approver** roles, and this requirement cannot be turned off for the company administrator. From the security screen of the portal, the company administrator turns the requirement on or off for the other ready-made roles. For custom roles the requirement depends on the role's own setting.

The same screen sets the **idle timeout**: 15, 30 or 60 minutes (default 30). A session also has an absolute lifetime (default 12 hours); at the end of it the person signs in again. The session key is stored hashed on the server, the cookie is set so that browser scripts cannot read it, and protection against cross-site request forgery (CSRF) is applied to requests with a same-origin rule.

When there is a problem with a staff account, the company administrator unlocks the account, resends the invitation, resets two-factor authentication or closes the account. Where these actions are found is described on the [company admin panel](/en/company-admin-panel/) page.

## Who can see what after signing in?

Signing in only proves identity; the data a person can see is limited by the role model. The portal has 9 action keys (view and make bookings, guest passenger, view and give approvals, reports, finance, view and edit administration) and 7 data scopes (the person themselves, specific people, their department, their branch, their company, their company and its sub-branches, the whole organisation). Seven ready-made roles are created automatically in every company, and custom roles can be defined too.

The model follows the principle of least privilege: a traveller sees their own trips, a department manager sees their department and the finance team sees the company's financial data. The approval action cannot be granted together with the "only themselves" scope. In approvals, the requester cannot decide at a level where they are their own approver; that level passes to their manager.

An approval link that arrives by email lets a person approve or reject without signing in, so it is protected separately. The link is **single-use**, only its hash is stored in the database, and it stays valid until the request's option deadline, or for 72 hours when there is no option.

## Which information never appears in the portal?

Commercial fields such as supplier name, net price, markup, commission and profit are never sent to the portal; ID numbers come back only masked, card details are not stored, and visa documents are opened only to the applicant. The privacy rule of the portal is not to hide a field on screen but never to put it in the response at all:

| Data | Behaviour in the portal |
|---|---|
| Supplier name, net price, markup, commission, cost, profit, margin | Removed from portal responses; a response that cannot be parsed is not sent to the portal at all (fail closed) |
| ID number | The unmasked value never appears in an API response; only the masked form, with the last 3 characters visible, is returned |
| Card details | Not stored; payment is taken as a single charge with a 3D Secure redirect |
| Visa documents | Served only through signed-in endpoints and seen only by the applicant; every file opening is written to an access log |

This table protects your agency as much as your corporate client: your net price and profit layer never reach the staff member's browser in any form. The document rules for visa applications are detailed on the [corporate visa management](/en/corporate-visa-management/) page, and the card payment rules on the [corporate travel payments and invoicing](/en/corporate-travel-payments-and-invoicing/) page.

## How is a trail of decisions kept?

The critical decisions of travel and money movement are followed through persistent records: approval steps go to an event table, policy changes to a version history, wallet movements to an immutable ledger and visa document openings to an access log. The points where records are kept are:

- **Approval events:** steps of an approval request such as decisions, escalations and alternative choices are written to an event table; decisions given by a delegate are marked "as delegate" in the history. The same record also feeds the live flow on the approval screen.
- **Policy versions:** every policy save creates a new version; the person who published the version and the date are stored, and two versions can be compared.
- **Company wallet:** the transaction ledger is immutable; a correction can only be made with a new correction entry.
- **Visa documents:** every document opening is written to an access log.
- **Pricing rules:** for the markup rules on the agency side, the before and after state of a change is recorded.

These records keep the trail of travel and money movement. There is no separate administration audit log screen for changes to roles, staff and security settings; we recommend telling your corporate client about this distinction plainly.

## Does the portal have SSO, IP restriction or directory sync?

No. The corporate portal currently has no **SSO sign-in based on SAML or OIDC**, no **LDAP / Active Directory** connection and no directory sync with **SCIM**. Restricting sign-in by IP address is not offered as a feature either. Sign-in is done with email and password, two-factor authentication that can be made mandatory by role, and passkeys. Staff records are created one by one by invitation or with a bulk Excel upload. You can find the definition of the concept in the [SSO (single sign-on)](/en/glossary/sso/) glossary entry.

## What does the portal offer for KVKK?

KVKK is Turkey's personal data protection law, [Law No. 6698 on the Protection of Personal Data](https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law) (English text on the Personal Data Protection Authority website, accessed 4 November 2026), published in the Official Gazette on 7 April 2016. The portal provides a **KVKK privacy notice and consent flow**:

- Staff cannot open their account without approving the KVKK text at invitation acceptance.
- The corporate account request form on the portal's landing page asks for KVKK consent.
- A visa application collects three separate approvals: accuracy, KVKK explicit consent and terms.
- The KVKK, privacy, terms of use and cookie texts are defined separately for each language and published in the portal; the texts are defined in the settings of the corporate site.

The portal does not claim a KVKK certificate; assessing legal obligations belongs to the legal processes of the agency and the corporate client. We describe the legal framework in [business travel data protection (KVKK and GDPR)](/en/blog/gdpr-and-data-security-solutions-in-corporate-travel-is-your-information-safe/).

## What is declared about infrastructure and payment security?

DIJI.TECH states that the platform runs on **AWS and Cloudflare** infrastructure and uses a **PCI DSS compliant payment infrastructure**. On the application side there is a separate encryption service for supplier account credentials, and card details are not stored in the portal. Diji, the AI assistant inside the portal, works within the same framework: it acts with the staff member's own permissions, masks sensitive data such as passwords, tokens and card numbers, and deletes conversations after 12 months. The details are on the [AI travel assistant](/en/ai-travel-assistant/) page.

When you answer the security questions of a corporate client, you can use this page as a starting document. How the portal is set up under your brand is described on the [white-label corporate booking tool](/en/white-label-corporate-booking-tool/) page; to see the security screens live, you can [request a demo](https://www.diji.tech/en/demo).

## Frequently asked questions
### How is data separated in the corporate portal?
Kurumsal.pro runs on a multi-tenant architecture, and the company and staff data of each tenant is kept in a separate database. The portal resolves which tenant an incoming request belongs to from its domain name; the portal does not open on a domain that has not been verified.

### Can two-factor authentication be made mandatory?
Yes. Two-factor authentication is required by role. By default it is required for the company administrator, finance and approver roles and cannot be turned off for the company administrator. The company administrator changes the requirement for the other ready-made roles from the security screen of the portal.

### Which two-factor method is used?
A 6-digit code generated by an authenticator app (TOTP) is used. Setup is done with a QR code or a manually entered key. The code step is valid for 5 minutes and allows at most 5 attempts. Two-factor authentication by SMS is not offered.

### What is passkey sign-in?
A passkey signs a person in with the device's fingerprint, face recognition or screen lock instead of a password. Staff add, list and delete passkeys from their profile. Passkey sign-in also goes through the account lockout and account status rules.

### What happens after wrong password attempts?
With default settings the account is locked for 15 minutes after 5 wrong attempts. Sign-in responses do not reveal whether an account exists. The company administrator can unlock a staff account from the portal when needed.

### Does the portal support SSO sign-in?
No. The corporate portal currently has no SSO sign-in based on SAML or OIDC, no LDAP or Active Directory connection and no directory sync with SCIM. Sign-in is done with email and password, two-factor authentication and passkeys.

### Are card details stored in the portal?
No. The portal does not keep card numbers; payment is confirmed on the 3D Secure verification page of the issuing bank. On the infrastructure side, DIJI.TECH states that the platform runs on AWS and Cloudflare and uses a PCI DSS compliant payment infrastructure.

### What does the portal offer for KVKK and data protection?
Staff cannot open their account at invitation acceptance without approving the KVKK privacy notice (KVKK is the Turkish personal data protection law). A visa application collects explicit consent. The KVKK, privacy, terms of use and cookie texts are defined separately for each language and published in the portal.