Security Controls

This page summarises the controls most often asked about in vendor-assessment forms. The detailed control matrix and the encryption description are shared under NDA — see Trust.

Encryption — data at rest

• Cardholder data: Encryption and decryption are performed by a hardware security module (HSM); encryption keys never reach the application layer. The database holds only the ciphertext of the card number. Detail: PCI DSS.
• Documents and biometrics: Objects are encrypted in the application layer before they are written to storage. A separate data key is derived per tenant and wrapped with a master key, using AES-256-GCM with associated-data authentication.
• Other personal data: Fields such as phone number, email, national identifier and tax number are encrypted at column level. Where those fields must be searchable, a blind (HMAC) index is used instead of plaintext.

Encryption — data in transit

• All traffic between your organisation and the platform is carried over TLS.
• Connections to the card encryption infrastructure additionally require certificate pinning.

Key management

• Tenant data keys are rotated every 90 days; rotation is serialised per tenant under a lock.
• Encrypted records carry the key version they were written with.
• Key management runs on infrastructure we operate ourselves; it is not delegated to a third-party cloud provider.
• Your own secrets (such as provider credentials) are held in a tenant-scoped secret vault with versioning; every access to the vault is written to an audit record.

Access and authorisation

• Customer access is layered: access token, request signature, publishable-key scope and, where required, step-up verification.
• Authorisation is role and permission based. If an endpoint requires a permission and permissions cannot be resolved, the request is rejected (fail-closed).
• Service-to-service calls pass token verification with an algorithm allow-list and issuer/audience checks; a call that cannot be verified is rejected.

Tenant isolation

• Every query is constrained by tenant identity, and cross-tenant access scenarios are exercised by a dedicated test suite.
• The identity verification service additionally enforces database row-level security (RLS).

Audit logging

In critical services the audit log is hash-chained: each row is derived from its own content and the hash of the preceding row, so insertion into the middle of the chain — or re-linking it — is detectable. Chain integrity can be checked with a separate verifier.

On the fraud side, case events are written to an append-only record together with the actor and the status transition, in the same transaction as the status change itself.

Log hygiene

• Card numbers are detected by Luhn validation and Turkish national identifiers by their check-digit algorithm, then masked; only sequences that pass validation are masked, so random order numbers are left intact.
• Tokens and authorisation headers are redacted.
• Request-body logging is limited to specific endpoints and always passes through redaction.

Abuse protection

• Rate limiting is applied on authentication endpoints; limiter keys are stored as hashes rather than plaintext.
• Outbound calls block private, loopback and cloud metadata addresses; pinning to the resolved address closes DNS rebinding.
• Automation connectors enforce a destination policy and a request body size limit.

Retention, erasure and legal hold

• Retention is not a single global number; it is resolved by data type and by country. Durations and scope: Compliance Overview and KVKK.
• Identity verification and identity/device signals provide operator-triggered erasure endpoints. Before any deletion occurs, the destruction engine writes an immutable manifest, and on completion it produces a signed destruction certificate.
• Erasure operations are written to an append-only erasure record and can be exported for audit.
• Data under legal hold is never removed from the archive or destroyed, even once its retention period has elapsed.

Change management

• Database migrations run before deployment completes; if a migration fails, the deployment stops.
• A service will not start while a migration is pending; this is a boot condition.
• Dependencies are installed from a pinned lockfile; an install that deviates from the lockfile cannot reach deployment.

Independent testing

We have commissioned independent penetration testing. A summary report that can be shared under NDA is in preparation and will be announced once ready. We do not publish the provider's name or the test date on this page.

Questions

For the control matrix, the encryption description or a vendor-assessment form: [email protected]