Security & Data Handling

1. Client Code and Data

We treat client code and data as belonging entirely to the client. We access it to do the work we have been engaged to do, and for no other purpose, not for training, not for benchmarking, not for reuse on another engagement, and not in marketing material without explicit written permission.

We prefer to work inside your environment wherever practical: your repositories, your cloud subscription, your development and staging environments, with accounts you issue and can revoke. This keeps your code and data under your control and your logging, and means access ends the moment you decide it should.

Where a local working copy is genuinely necessary, it stays on company-managed developer machines and is removed at the end of the engagement.

We ask for the least access that lets us do the job. If a task needs read-only access, we ask for read-only. If it needs production data, we will first ask whether anonymised or masked data would do instead and in our experience it usually would.

2. Production Data and Personal Data

Our default position is that we should not have access to live personal data unless there is no reasonable alternative. Debugging a data-specific defect sometimes requires it; building a feature usually does not.

Where we do need to work with production data, we agree the scope in writing beforehand: which systems, which datasets, for how long, and who specifically has access. Access is granted to named individuals rather than to the company generally, and it is withdrawn when the task that justified it is finished.

We do not copy production personal data into development or test environments as a convenience.

3. Confidentiality, NDAs and IP Assignment

We will sign your NDA before we look at your code. If you do not have one, we will provide ours, but we would rather work to yours, because it means your legal team has already approved the terms.

On intellectual property, our standard position is that everything we produce for you belongs to you. Work product, source code, documentation and designs created in the course of an engagement are assigned to the client on payment, with no residual licence retained by us and no claim over your pre-existing IP.

Where we use open-source components, we tell you what they are and under which licence, so you are never unknowingly taking on a licence obligation. We avoid copyleft licences in client deliverables unless you specifically ask for them.

Every engineer we put on an engagement is bound by confidentiality obligations to us that mirror the ones we owe you, so the commitment reaches the individuals actually doing the work.

4. GDPR and International Transfers

For UK and EU clients, we normally act as a data processor and you remain the controller. That means we process personal data only on your documented instructions, and we expect to sign a data processing agreement setting out the purpose, duration and categories of data involved.

Softwiz Infotech operates from India, so any personal data we process on your behalf involves an international transfer outside the UK and EEA. India is not currently the subject of a UK or EU adequacy decision, which means the transfer needs an appropriate safeguard, in practice the EU Standard Contractual Clauses, or the UK International Data Transfer Agreement or Addendum. We will enter into these as part of the engagement, and we would encourage you to require them of any offshore supplier, including us.

We will support you in meeting your own obligations: assisting with data subject access requests that touch systems we work on, notifying you promptly of any suspected personal data breach so you can meet your own reporting deadlines, and deleting or returning personal data at the end of the engagement.

We are not a controller of your customers' personal data and we do not use it for our own purposes at any point.

5. AI Tools in Delivery: Which, Where, and Training

Clients increasingly ask which AI tools we use to write software, whether their code passes through them, where that processing happens, and whether it is used to train a model. These are the right questions and they deserve direct answers rather than reassuring generalities.

Our position is straightforward. We will tell you which AI-assisted development tools we use before an engagement starts. If you prohibit them, we will work without them. If you permit them only on non-sensitive parts of the codebase, we will honour that boundary. This goes in the engagement terms rather than being left to individual judgement.

We select tools configured so that client code submitted to them is not retained for model training. For paid, business-tier developer tooling this is the standard contractual position, but it depends on the specific product and plan, so we confirm it per tool rather than assume it.

For AI features we build into your product, the data flow is yours, not ours. Our default is to deploy models within your own cloud tenant, for example Azure OpenAI in your subscription, so that prompts, retrieved context and completions remain inside your compliance perimeter and your logging. Azure OpenAI does not use customer data submitted through the service to train the underlying models, which is a large part of why we prefer it for regulated work.

Where a use case genuinely requires a third-party model outside your tenant, we will say so explicitly, identify the provider, and set out what data would leave your environment before you commit to that design rather than after.

We do not put client code, client data, or personal data into consumer-grade AI tools or free tiers.

6. Access Control and Offboarding

Access is granted per person and per engagement, never as a shared team credential. Where you issue accounts, we ask that each engineer receives their own, so your audit log shows individuals rather than a generic contractor account.

We keep a record of who holds access to what for each engagement, and we review it when the team composition changes rather than only at the end.

When an engineer leaves an engagement or leaves the company, their access is revoked. We will tell you when someone rotates off so you can confirm removal in your own systems because your revocation is the one that actually matters, and relying on a supplier to remember is poor practice on both sides.

At the end of an engagement we hand over everything: code, documentation, credentials we hold, and any deployment knowledge needed to run the system without us. We then remove client material from our systems.

7. Certifications: Where We Actually Stand

We do not currently hold ISO 27001, SOC 2, or any comparable independently audited security certification. We would rather state that plainly than imply a posture we cannot evidence.

What we can offer instead is specificity: we will answer a security questionnaire, walk your team through how we would handle your code and data, accept your contractual terms on confidentiality, IP and data protection, and agree to your access and audit requirements in writing.

If your procurement process requires a certified supplier, we would rather tell you now than waste your evaluation cycle.

8. Reporting a Concern

If you have a security concern about anything we have built or any access we hold, contact us at hello@softwizinfotech.com and mark it as a security matter. We will acknowledge it and tell you what we are doing about it.

If you believe you have found a vulnerability in a system we maintain, please report it to us rather than disclosing it publicly, and we will work with the system's owner to get it resolved.