Data Protection

Last updated: 20 Aug 2026

This page is for the security, IT and procurement teams evaluating us. It sets out how we protect the data our clients trust us with, and — just as importantly — who is responsible for which part of it. If you are an individual wanting to know what we do with your personal information, our Privacy Policy is the page you want.

Security is a shared responsibility. This page describes the controls we operate at the application layer, and identifies which layers sit with you or with a hosting provider, so that expectations are clear from the outset rather than assumed.

Our role

When we build or operate a system for you, the personal data inside it belongs to you. You are the Data Fiduciary under India’s Digital Personal Data Protection Act, 2023, or the controller under GDPR. We are the processor, and we act only on your documented instructions.

We do not use client data for our own purposes — not for product development, not for marketing, and not for training any model — unless you have specifically agreed in writing.

Where your system runs

Client systems are hosted on your own server where you provide one, or on a server we procure on your behalf. Where a project requires data residency in a particular jurisdiction, tell us during scoping and we will architect for it.

This matters for what follows, because it determines who controls which layer.

Who is responsible for what

Layer	Your own server	Server we procure
Physical and network infrastructure	You, or your provider	The hosting provider
Operating system and server hardening	You, or your provider	The hosting provider, under their managed terms
Backups and disaster recovery	You, or your provider	The hosting provider
Encryption at rest	Depends on your provider’s capability	Depends on the provider’s capability
Application code and its security	Us	Us
Authentication, access rules and data handling in the application	Us	Us
Transport encryption (TLS)	Us, with your provider	Us

Put simply: we are responsible for the application. The server layer belongs to whoever owns the server. We will tell you honestly during scoping what a given hosting choice does and does not give you, and where a stronger option is worth the extra cost.

Where you want a control implemented at the application layer that is not listed as standard below — multi-factor authentication, audit logging, IP restrictions, single sign-on — ask during scoping and we will build it in.

How we build

This is the layer we own outright, so it is where we can be specific.

• Injection and input handling. Database queries are parameterised, and input is validated and output encoded, so that user input cannot be executed as code.
• Passwords are hashed, never stored in a readable form and never recoverable — we can only reset them.
• Sensitive parameters are encrypted. Where data has to be passed between pages or systems, we use hash-key based encryption rather than exposing values in a query string.
• Forms are protected against automated abuse, using Cloudflare Turnstile or Google reCAPTCHA depending on the project.
• Cloudflare in front of the domain is our default recommendation, for DNS, TLS and protection against automated traffic.
• Separate environments. Development, staging and production are kept apart, and we work against anonymised or sample data rather than production data wherever the task allows.
• Version control and review. Code is version controlled and changes are reviewed before reaching production.
• We do not roll our own cryptography. We use established libraries and standard algorithms.

We do not currently run automated dependency scanning or static code analysis. Where a project warrants it, we will include it in scope and say so.

Encryption

In transit. Traffic is encrypted using TLS 1.2 or higher, on every system we deliver.

Within the application. Passwords are hashed. Sensitive values passed between pages or systems are encrypted using hash-key based encryption rather than travelling in clear text.

At rest. Disk and database encryption is a function of the server, so it depends on the hosting arrangement. Where you need encryption at rest, tell us during scoping — we will either confirm your provider supports it or recommend one that does. We will not tell you it is in place when the underlying server does not offer it.

Access control

• Access to client systems is limited to team members working on that engagement, on a least-privilege basis.
• Access is revoked when someone moves off a project or leaves the company.
• Production credentials are not stored in source control.
• Where you provide us with access to your own systems, we ask that you grant the minimum needed and revoke it at the end of the engagement. Please do tell us when you have.

Backups and recovery

Backups belong to the server layer, so responsibility follows the server.

• On your own server — backups are your responsibility, or your hosting provider’s under whatever plan you hold.
• On a server we procure — backups are provided by that hosting provider under their plan. We will tell you what the plan includes before you commit to it.

We can build application-level export or backup routines into a project where you want them. Ask during scoping.

One thing worth saying plainly: check that your backups restore. A backup nobody has ever restored from is an assumption, not a backup. If you would like us to run a restore test with you, we will.

Where a project agreement sets specific recovery objectives, those apply in place of this section.

Retention and deletion

We hold client data for as long as we are engaged to hold it, plus any period the law requires.

Where we host on your behalf, data may be deleted thirty (30) days after termination unless your agreement says otherwise — take your own export within that window. On written request we will delete sooner and confirm when it is done, subject to any legal retention obligation.

Sub-processors

We use third parties to deliver parts of our service. Those relevant to client data are:

• Hosting — Amazon Web Services, Hostinger, GoDaddy or Bluehost, selected per project according to your requirements and budget. We will tell you which is proposed before anything is provisioned.
• Google Workspace — business email.
• Zoho ZeptoMail — transactional and API-based email delivery.
• Zoho Desk — support ticketing.
• Meta Platforms — where messaging services are used.
• Cloudflare — DNS, TLS and bot protection where deployed.

Each is bound to confidentiality and to use data only for the service it provides. Where we plan to add a sub-processor that will handle your data, we will tell you.

If something goes wrong

Where a breach affects your data, we will notify you without undue delay and in any case within seventy-two (72) hours of becoming aware of it.

We will tell you what we know, what we do not yet know, and what we are doing about it — and we will keep telling you as the picture develops. We will not wait to complete our own investigation before informing you, because your own notification deadlines start running from when you find out.

We will support you in meeting your obligations to regulators and to affected individuals.

Your responsibilities

Because the controls described above are shared, the following remain with you:

• Keeping your own accounts, devices and credentials secure, and telling us promptly if any are compromised.
• Managing who inside your organisation has access to the system, and removing access when people leave.
• The security, configuration, patching and backups of any server, network or third-party service you provide or control.
• Ensuring you have a lawful basis for the personal data you place into the system, and that it was collected with the notices and consents the law requires.
• Telling us at scoping about any regulatory, contractual or sector-specific requirement that applies to your data. We cannot design for a requirement we are not told about, and retrofitting one after delivery is chargeable additional work.
• Reviewing and accepting deliverables, including any security-relevant configuration handed over to you.
• Anything done to the system by you or a third party after handover. Where a system has been modified by someone other than us, our responsibility for it ends.

Requests from individuals

If someone approaches us about data held in a system we run for you, we will not act on it directly. We will refer them to you and help you respond within your own deadline. That is the correct handling — the decision is yours, not ours.

Our people

Employees and contractors are bound by confidentiality obligations that survive the end of their engagement with us. Access is granted when someone joins a project and removed when they leave it.

Compliance

We operate under India’s Digital Personal Data Protection Act, 2023 and the Information Technology Act, 2000 together with its reasonable security practices rules.

Where a client serves customers in the UK or the European Economic Area, we will enter into GDPR-compliant processing terms, including standard contractual clauses where required.

Our compliance approach

We operate a defined set of controls rather than a certification programme, and they are set out on this page: least-privilege access, separated environments, reviewed code, hashed credentials, encrypted transport and sensitive values, protected forms, and a defined breach notification commitment.

Where your organisation has specific compliance requirements — a framework you need us to align to, controls you need implemented at the application layer, or contractual security terms — raise them during scoping. We will tell you what we can meet, what would need to be built, and what it would cost, before you commit to anything.

Data processing agreements

We are happy to sign a data processing agreement, and can work from your template or provide ours. Ask your account manager, or write to [email protected].

Security questionnaires

If your procurement process includes a security questionnaire, send it over and we will complete it. Where an answer is “not currently”, we will say so rather than stretch a definition. You would find out eventually, and it is better for both of us if that happens before the contract rather than after.

Scope of this page

This page describes our general practices. It is provided for information and does not form a warranty, guarantee or service level commitment.

The controls applied to any particular engagement are those set out in the agreement, statement of work or data processing agreement signed for it. Where this page and a signed agreement differ, the agreement governs.

No system can be made perfectly secure, and we do not represent otherwise. We are not responsible for the acts, omissions, outages or security failures of hosting providers, network operators, third-party platforms or software we do not control. Our liability is limited as set out in our Terms and Conditions.

We may update this page as our practices develop. The date at the top shows the last revision.

Contact

Security or data protection questions, including anything you would rather raise privately, go to [email protected].

If you believe you have found a vulnerability in one of our systems, please tell us at that address before disclosing it publicly. We will acknowledge you, investigate, and keep you informed.