When you hire a software company, you hand over more than a project brief. You give them access to your systems, your data and often your customers' personal information. It is reasonable to ask how that trust is protected. This article describes our standard practice. Our quality and information security management practices are aligned with ISO 9001 and ISO 27001, and the specifics for each project are agreed with the client.
Before the project starts
We sign non-disclosure agreements with clients, and everyone who works with us is bound by confidentiality. At the start of a project we agree what data we actually need. If a task can be done without real personal data, we work without it.
Access
People get access only to the systems and data their work requires, using individual accounts rather than shared logins, so every action can be traced to a person. When someone no longer needs access, at the end of a project or when they change role, it is removed. We ask clients to grant us access the same way, through individual accounts that can be withdrawn at any time.
Code
All code is kept in version control from the first day, never only on a developer's laptop. Every change is reviewed by another engineer before it is merged. Reviews catch security problems as well as bugs, and they make sure more than one person understands each part of the system.
Secrets
Passwords, API keys and connection strings do not belong in source code. We keep them out of the code repository and store them separately for each environment, so that a developer's copy of the code does not hold production credentials.
Environments
Development, testing and production are kept separate. New work is tested away from the live system, and clients check it before it goes live. Real personal data is not copied into test environments unless that has been agreed with the client and is properly protected.
Dependencies
Modern software is built on open-source packages, and those packages sometimes have security flaws. We scan the dependencies our projects use for known vulnerabilities and keep them updated, including after launch for the systems we support.
Releases
Releases follow a planned, repeatable process rather than manual copying of files, so every release is done the same way and can be rolled back if something goes wrong.
Backups
For systems we host, backups are taken regularly and protected with encryption. A backup that has never been restored is only a hope, so restoring from backup is part of how we test our setup.
When something goes wrong
If we find or suspect a security incident affecting a client, we contain it, investigate it and tell the client promptly, with the facts as we know them. Afterwards we look at what allowed it to happen and change our practice to prevent a repeat.
Suppliers
Hosting providers and third-party services become part of your system's security. We choose them with that in mind, prefer established providers, and review our choices over time.
People
Most security failures involve people, not technology. Everyone who works with us is made aware of their responsibilities: handling client data carefully, recognising phishing, protecting their devices and reporting anything suspicious straight away.
Personal data
We handle personal data in line with India's Digital Personal Data Protection Act, 2023, and agree with international clients how GDPR requirements will be met before work begins.
Handover
How code, documentation, accounts and credentials are handed over is agreed in each contract, so you are never dependent on us to keep your own system running.
You can read more about how we work on our Quality & Security page. If you would like to discuss the security requirements of your own project, book a free consultation.