Security, IP And Compliance
How we handle your code and your data
Including a list of the certifications we do not hold.
Everything on this page is a commitment we will put in a contract. Everything we cannot commit to is on it as well, because finding that out in week three of procurement helps nobody.
Quick Answer
Updated August 22, 2026
How does SoftwareCrafting handle security, IP, and compliance?
A mutual NDA is signed before technical detail is shared and IP assignment before work begins, so all code and designs are yours on creation rather than on payment. Work happens in your repository under your organisation from the first commit, using named individual accounts with least-privilege access that is revoked the day an engagement ends. Secrets never enter the repository, production data is not copied to developer machines, and MFA is required on every account. For EU work we sign a data processing agreement with standard contractual clauses; for Indian users we build to the DPDP Act. We are not SOC 2 or ISO 27001 certified — we are a seven-person team and neither is proportionate — and we say so rather than implying otherwise.
IP assignment
Before work begins
Repository
Yours from commit one
Certifications
None — stated plainly
Best for
- Procurement teams running a vendor security review
- Buyers who need IP and data terms settled before a call
- Regulated products needing GDPR or DPDP-aware architecture
Not best for
- Procurement that mandates a SOC 2 or ISO 27001 certified supplier
- Work that cannot legally leave your jurisdiction
- Engagements needing us to act as an independent security auditor
Contractual Commitments
What we will put in writing
| Area | Commitment | What that means |
|---|---|---|
| NDA | Signed before technical detail is shared | Mutual NDA as standard, on your paper or ours. Nothing about your product, architecture, or roadmap leaves the engagement. |
| IP assignment | Signed before work begins | All code, designs, and documentation produced for you are yours on creation, not on payment or on handover. |
| Repository | Yours from the first commit | We work inside your GitHub, GitLab, or Bitbucket organisation. We do not develop in our own accounts and hand over later. |
| Credentials | Least privilege, revoked on exit | Named individual accounts rather than shared logins, scoped to what the work requires, removed on the day an engagement ends. |
| Multi-factor authentication | Required on every account | On our own systems and on any client system we are granted access to. |
| Secrets | Never in the repository | Environment variables and managed secret stores only. We audit for committed secrets when we inherit a codebase, and it is a common finding. |
| Production data | Not copied to developer machines | We work against anonymised or synthetic data. Where production access is genuinely required for debugging, it is time-boxed and logged. |
| Devices | Disk encryption and screen lock enforced | We can also work within your device policy or VDI where you have one. |
| Sub-processors | No undisclosed subcontracting | The engineers named in your contract do the work. We do not resell your project to another agency. |
| Data deletion | On request, and at engagement end | Written confirmation of what was deleted and when, if you need it for your own records. |
The Honest Part
What we are not
Security pages usually imply more than they say. This is the part ours says outright, because if one of these is a hard requirement for you, both of us are better off knowing on day one rather than in week three of procurement.
- We are not SOC 2 certified. We can prepare the infrastructure evidence for your own audit, but the report would be yours, not ours.
- We are not ISO 27001 certified. If your procurement requires a certified supplier, a larger firm is genuinely the right answer and we will say so early.
- We are not a HIPAA business associate by default. We have built HIPAA-shaped controls into healthcare products, and we will sign a BAA where the engagement warrants it and your counsel approves the terms.
- We do not perform penetration testing ourselves. That should come from an independent specialist; we remediate the findings.
In The Build
Security practices that ship with the code
Not a hardening phase at the end. These are defaults, and they are included in the rate rather than quoted separately.
Encryption in transit and at rest
TLS everywhere, database and storage encryption enabled by default rather than as a later hardening step.
Authentication and session handling
Modern password hashing, refresh-token rotation, session invalidation on password change, and rate limiting on every auth endpoint.
Authorisation checked server-side
Every permission decision enforced on the server. Hiding a button is not access control, and it is a finding we make regularly on inherited code.
Dependency and vulnerability management
Automated dependency updates with review, and security advisories triaged rather than batched until something breaks.
Input validation at the boundary
Schema validation on every external input — request bodies, webhooks, uploads — so types reflect what actually arrives.
Audit logging where it matters
Who did what and when, on anything involving money, personal data, or permission changes, with retention you can defend.
Backups that have been restored
Backups are configured and then actually restored in a test, because an unverified backup is a belief rather than a control.
Incident response
A named contact, a written runbook, and notification to you without delay. We will tell you about a mistake we made before you find it.
FAQ
Security and compliance questions
Will you sign an NDA?
Yes, as standard and before technical detail is shared. On your paper or ours. We also sign IP assignment before work begins, so ownership is settled before there is anything to argue about.
Who owns the code and the intellectual property?
You do, on creation. IP assignment is signed before any technical work starts, and all work is committed to your repository under your organisation from the first commit. We do not retain rights, and we do not develop in our own accounts and hand over later.
Are you GDPR compliant?
We work within GDPR as a data processor: a data processing agreement, standard contractual clauses for transfers to India, documented sub-processors, and architectures that keep EU personal data in EU-hosted infrastructure where required. Compliance is a property of your product and your obligations, not a badge a supplier holds — but we build so that yours is achievable, and we will not pretend the cross-border element is nothing.
What about India’s DPDP Act?
For products serving Indian users, we build to the DPDP Act’s expectations around consent, purpose limitation, and data-principal rights. Where you serve both Indian and EU users, the two regimes overlap substantially and we design once to the stricter requirement.
Are you SOC 2 or ISO 27001 certified?
No, and we would rather say so plainly than imply otherwise. We are a seven-person team and neither certification is proportionate to our size. We can prepare infrastructure evidence for your own audit, and if your procurement requires a certified supplier, a larger firm is the right answer.
Can you work under our security policy?
Usually yes — device policy, VPN or VDI access, restricted networks, and named-account provisioning are all workable. Tell us the constraints early, because a few of them change how the engagement is structured and therefore what it costs.
How do you handle access when someone leaves the project?
Access is revoked on the day, not at the end of the month. We use named individual accounts rather than shared credentials specifically so that revocation is clean and auditable.
Do you use client data to train AI models?
No. We do not train models on client data, and where we build AI features we use API providers under terms that exclude training on submitted content. If a project needs a specific contractual guarantee on this, we will get it in writing from the provider.
Do you use AI coding tools on our project?
Yes, as assistance, under human review — every line is read by an engineer and goes through the same review process as anything else. If your policy restricts this, tell us and we will work within it.
Can you complete our vendor security questionnaire?
Yes. Send it over and we will complete it honestly, including the questions where the answer is "no". That is faster than discovering a gap three weeks into procurement.
Vendor Review
Send us your security questionnaire
We will complete it honestly, including the questions where the answer is no, and return it with the supporting detail your reviewer will ask for next. If a requirement rules us out, we will tell you in the first reply rather than at the end.
Also useful during procurement: the company facts page for registration and identity details, and the working-with-us FAQ for contract, payment, and handover terms.
Quick Brief
Start the conversation here
Send your security questionnaire or your specific requirement. We answer honestly, including where the answer is no.
Your Name
Work Email
What do you need help with?
Reference
The rest of the reference material
Facts, contract terms, onboarding, and the vocabulary behind all of it.