Security Statement
Our engagements put us inside claims queues, AP ledgers, KYC files, and HR records. That access is the thing most worth asking us about during diligence, so this page sets out how we handle it - separately from how this marketing website behaves.
Last updated 23 July 2026
This website
The site is a static export served over HTTPS. There is no application server, no database, and no administrative login attached to it, which removes most of the attack surface a marketing site normally carries.
The only data path is the contact form described in our Privacy Policy. The form includes a hidden spam trap and submits over TLS to our form provider. No data submitted through this site is stored on the website itself.
Client data in delivery engagements
The default posture is that client data stays in the client's environment. Automation, RPA, and AI workflows we build are deployed into your tenancy, on your infrastructure, under your identity provider - not into a KLS-operated environment that then holds your records.
- Access is least-privilege and role-scoped, provisioned through your IAM, and revoked at engagement close as a checklist item, not on request.
- We work against masked, synthetic, or subset data in development and test environments wherever the workflow allows it.
- Production data is not copied to KLS laptops, personal accounts, or unmanaged storage.
- Every engagement runs under a signed NDA, and under a data processing agreement where personal data is in scope.
How AI components handle your data
This is the question enterprise risk teams ask first, so we answer it plainly. Where an engagement uses a third-party model provider, we use enterprise or API tiers under terms that exclude customer content from provider model training, and we agree the specific provider and region with you before any data flows to it.
- Model providers, regions, and data-residency constraints are agreed in writing during design, not assumed at build time.
- Prompts and responses that touch regulated data are logged to your environment so they are auditable by your teams.
- Retrieval-based assistants are grounded in approved source documents with access controls inherited from the source system - an employee cannot retrieve through the assistant what they could not open directly.
- Human approval sits on any step where an incorrect automated decision would carry financial, legal, or safety consequence.
People and access
Engagement teams are named. Consultants and engineers deployed into client environments are background-verified before onboarding, bound by confidentiality terms, and off-boarded through a documented access-revocation step when they roll off.
Sub-processors
For this website, our sub-processors are listed in the Privacy Policy. For delivery engagements, the sub-processor list is engagement-specific and provided in writing as part of contracting - we do not introduce a new sub-processor into a live engagement without telling you first.
Reporting a vulnerability
If you believe you have found a security issue in this website or in something we built for you, email us with the detail and we will acknowledge within two business days. Please do not test against production client systems.