Governance & security

The questions
procurement asks first.

Answered here rather than in a questionnaire three weeks into a deal. Where a control is aspirational rather than in place, this page says so — a supplier who overstates their posture is a risk in itself.

Least-privilege accessScoped to what each system needs, reviewed at handover.
You own the IPDelivered work transfers on final payment.
Your infrastructureData stays in your accounts wherever architecture allows.
Written before signedData handling documented before a build starts.
Data handling

Where your data lives

Ownership
All client data remains the client's property throughout and after the engagement. We claim no licence to use it for any purpose beyond delivering the agreed work.
Location
Wherever the architecture allows, systems run in your cloud accounts and data never leaves your tenancy. Where we host on your behalf, region is agreed in the statement of work — including India-resident hosting where you require it.
Access
Engineers receive the minimum access required for their task, granted for the duration of the work and revoked at handover. We ask for named individual accounts rather than shared credentials, and we will decline shared logins.
Production data in development
We do not copy production data into development environments. Where realistic test data is needed, we generate or anonymise it.
Retention
On engagement close we return or destroy client data and credentials on request, and confirm in writing what was removed.
Sub-processors
Any third-party service that would process your data — hosting, model providers, analytics — is named in the statement of work before it is introduced, not added silently mid-build.
Engineering security

Controls built into delivery

Security handled as a delivery practice rather than a pre-launch audit that finds everything too late to fix cheaply.

Secrets management

Credentials held in a secrets manager or the platform's own store, never in source control, configuration files or a shared document. Rotation procedure documented at handover.

Code review on everything

All changes reviewed before merge regardless of author or urgency. Review is the primary control against both defects and unreviewed access changes.

Dependency hygiene

Dependencies pinned, audited for known vulnerabilities, and updated on a schedule rather than only when something breaks. Retained clients get this continuously.

Access control by design

Role-based permissions and audit trails on record changes are treated as build requirements in any system holding operational or personal data.

Environment separation

Development, staging and production kept separate with distinct credentials. Production access is limited and logged.

Reversible releases

Every release has a rollback path established before deployment. Backups configured and restore-tested rather than assumed.

AI systems

How we govern AI components

AI in a business process is a reliability question before it is a capability question.

Human review thresholds
Anything customer-facing or financially consequential ships with a confidence threshold. Below it, the case routes to a person rather than proceeding on a guess.
Traceability
Inputs, outputs and the model version behind each decision are logged, so a wrong answer is diagnosable after the fact rather than mysterious.
Data sent to model providers
Named in the statement of work, minimised to what the task requires, and subject to your approval. Where a provider's terms permit training on submitted data, we disable it or do not use that provider.
Fallback behaviour
Every automated path has a defined behaviour when the model is unavailable or the response fails validation. The system degrades to a queue, not to silence.
Evaluation before launch
Accuracy measured against a labelled sample from your own data before go-live, with the result shared whether or not it flatters the build.
Service levels

Response and support

Applies to retained clients. During a build, the delivery team is available through the working week and reachable on the agreed channel.

SeverityDefinitionTarget response
S1 — CriticalProduction down, or data at risk. No workaround.Within working hours, immediately on notification; outside them, as agreed in the SOW
S2 — MajorCore function unusable for multiple users. Workaround painful or absent.Same working day
S3 — MinorFunction impaired with a viable workaround.Next working day
S4 — RequestChange request, question or enhancement.Scheduled into the change allowance

Stated plainly: specific response times and any out-of-hours cover are agreed per contract and written into the statement of work. We would rather commit to a number in your agreement than publish one here that does not match what you have signed.

Commercial & legal

Contracts, IP and continuity

Entity
KaizenSpark Tech Private Limited, incorporated November 2024, registered in Tamil Nadu, India. Registration details available on request for vendor onboarding.
Contracting
A statement of work per engagement. We work under your MSA, NDA and supplier terms where you have them rather than insisting on our paper.
Intellectual property
Ownership of work produced under the engagement transfers to you on final payment. Pre-existing components and open-source dependencies are listed with their licences at handover.
Confidentiality
We do not publish client names, screenshots or figures without written approval — which is why our work page describes builds rather than naming them.
Continuity
Documentation, runbooks and environment setup are delivered as part of the build specifically so you are not dependent on our availability. You should be able to hand the system to another supplier without calling us.
Certifications
We hold no formal security certification at present and will not imply otherwise. What we offer instead is documented practice, and we will complete your security questionnaire honestly — including the questions where the answer is no.

Send us your questionnaire.

If your procurement process has a security or vendor assessment form, send it early. We would rather fail it in week one than in week nine.