Security

Tenant isolation

Customer organisations are isolated at both the application and database layers. Data access is scoped to the active organisation on every request, and automated tests verify these boundaries across protected routes and services.

Access control

Role-based permissions are enforced consistently in the interface, API and service layer. Users can access only the data and actions assigned to their role.

Permission checks are covered by automated tests, including checks at the underlying service boundary.

Encryption

In transit: data is protected with HTTPS, including communication between internal services.

At rest: databases and stored files are encrypted.

Sensitive credentials: channel credentials and other secrets are encrypted separately before storage, with encryption keys kept outside the application database.

Multi-factor authentication is available for every account through authenticator apps, with single-use recovery codes. MFA secrets are encrypted and sign-in protections apply to invalid codes.

Passwords are stored using a modern password-hashing algorithm and checked against known-compromised password data without transmitting the password.

Sessions: short-lived access tokens and rotating refresh tokens reduce the impact of a compromised session.

Application logs are processed through automated secret redaction, with tests covering sensitive keys and credential formats.

Customer data access logging

Access to customer details through the order workflow is recorded with the user, time, source address, and affected records. This gives investigations a specific record of access rather than only an aggregate count.

Access records contain identifiers such as an order ID, not copied customer details. Search terms are excluded because they may themselves contain personal data.

Access records are retained for twelve months. Customer-data reads covered by this control fail closed if the access record cannot be written.

A separate audit trail records key changes, including the actor, affected record and relevant before-and-after values.

Unusual access volumes are monitored. Alerts identify the account and access count without copying customer records into the notification.

Access activity is available for review. Review views show access counts by account over selected periods without displaying customer details.

Infrastructure

The application and database are hosted in the United Kingdom, with the database available only on a private network. Files are stored in the European Union, and external traffic is protected by managed DNS, TLS and edge security services. The current provider list is on the sub-processors page.

Services use separate identities and limited permissions. Production credentials are managed outside application source code, and required security configuration is validated during deployment.

Backups

The database is protected by daily provider-managed backups and point-in-time recovery. Recovery procedures are documented and verified against restored data.

Secure development and release

Changes are checked through repeatable type, lint, unit and tenant-isolation test suites. Application releases use an automated build and migration pipeline with deployment gates.

Changes are scanned for exposed secrets, and dependencies are checked for known vulnerabilities. Production releases use controlled deployment automation.

Incident response

Security incidents are classified, contained, investigated and communicated under the response process below.

Severity classification

Severity	What it means	Examples
Critical	Personal data has been, or may have been, exposed to an unauthorised party	One merchant sees another's data; a database copy leaves our control; a credential store is opened
High	A control that protects data has failed, with no confirmed exposure	An authentication or permission bypass; a leaked credential with access to production
Medium	A weakness with no exposure and no failed control	A vulnerable dependency in a reachable path; a misconfiguration found before it was used
Low	A security event with limited impact	A report that turns out not to be exploitable

Response targets

Response targets begin when Channekt becomes aware of a potential incident.

By when	What happens
1 hour	An incident owner is assigned, containment begins and a response timeline is opened
24 hours	Affected merchants receive an initial written notice with confirmed facts, open questions and the next update time
72 hours	Affected merchants receive the available information needed for any regulatory notification, including scope, likely consequences and mitigation
10 working days	Affected merchants receive a written incident review and corrective actions

Response process

Containment. Revoke affected credentials, restrict compromised access and isolate the affected service path.

Evidence preservation. Relevant logs, access records and audit events are preserved before affected components are rebuilt or replaced.

Establish who saw what. Access records from the customer-data workflow are reviewed alongside authentication, application and audit logs to determine the affected users and records.

Notification. The merchant, as controller, receives the facts needed for customer or regulatory notification. Channekt contacts a merchant's customers only on the merchant's written instruction.

Remediation and review. Corrective action addresses the immediate issue and its underlying cause. Relevant automated checks are added or updated, and the outcome is documented.

Who to contact

During an incident, and to report one: support@channekt.com. It is monitored on working days and acknowledged within one working day.

This plan is reviewed every six months and after any incident of High severity or above. Review outcomes are documented.

Customer data retention

Order data is a merchant’s commercial record and we keep it for as long as they hold an account. Personal details on marketplace orders are different: the marketplaces we connect to set their own limits, and we honour the tightest one they impose.

For Amazon orders, a scheduled process removes the buyer’s name, email address, telephone number and street address thirty days after dispatch. The order, line items, financial values and destination country remain for operational and accounting records.

Customer details from a merchant-operated shop remain subject to the merchant's own retention instructions and legal obligations.

Reporting a vulnerability

Send it to support@channekt.com with enough detail to reproduce it. We will acknowledge within one working day, tell you what we found, and tell you when it is fixed. We ask that you do not access, change or keep anybody else's data while demonstrating a problem, and that you give us a reasonable chance to fix it before publishing.

Contact

Axicom · support@channekt.com