Security and Data Protection

During development we separate environments, so work happens against non-production data wherever possible and real production data is kept off developer machines. Access to any sensitive data is limited to the people who need it, over encrypted connections, using named accounts with least-privilege permissions. Secrets such as API keys and database credentials live in a secrets manager, not in source code. Code is reviewed before it is merged, and dependencies are scanned for known vulnerabilities. Backups are taken and tested, so a mistake during development does not become data loss. The specific measures scale with how sensitive your data is.

Access is limited to the people who need it for your project, and no more. That usually means the delivery team assigned to your work, a lead, and where relevant a reviewer, each with a named account rather than a shared login. We apply least-privilege access, so a developer sees the systems their task requires and not the rest. When someone leaves the project or the company, their access is removed as part of a structured offboarding step. Access to production data and infrastructure is tighter still, and it can be held entirely by your side when your policy requires that.

Yes. We sign a non-disclosure agreement before any sensitive detail is shared, usually before the first detailed requirements conversation. For work that involves personal data, we also sign a data-processing agreement that sets out what we process, why, the security measures in place, and how a breach would be handled. If your organization has its own NDA or DPA templates, we will work from yours. These are standard parts of how an engagement starts, not add-ons, and they sit alongside the ownership terms that keep your code, data and accounts yours throughout.

Where your data is hosted is your decision, guided by your policy and any regulation you answer to. We offer in-country hosting where data must stay onshore, Gulf-region cloud for low latency across the GCC, and UK or EU regions for clients aligning with European rules. We can also deploy to your own cloud account or on-premise servers, so the infrastructure stays entirely under your control. We will describe the trade-offs of each option in plain terms, including cost, latency and who carries operational responsibility, and then write the chosen arrangement into the agreement.

We follow an agreed incident-response path with four stages: detection, communication, remediation and review. Detection comes from monitoring and alerting on the systems we support. Once something is confirmed, we tell you promptly through the agreed channel, with what we know and what we are doing, rather than going quiet. Remediation contains the issue, fixes the cause and restores normal service, with a rollback plan where needed. Afterward we run a post-incident review that records what happened, why, and what changes so it is less likely to recur. The exact contacts and timelines are set in your contract.

We follow GDPR-aligned practices for clients in the UK and EU, and we back them with contractual commitments rather than marketing claims. In practice that means data minimization, a clear purpose for the data we process, support for data-subject requests routed through you as the controller, encryption in transit and at rest, and hosting in a UK or EU region when residency matters. We sign a data-processing agreement that sets out roles, security measures and breach-notification duties. We describe our practices and put them in the contract, and we do not offer a certification in place of doing the work.

Usually yes, and the way to find out is to share it early. We will read your security policy, map it against how we work, and tell you honestly where we already align, where we can adapt, and where a requirement would change the timeline or cost. Common requirements such as least-privilege access, named accounts, environment separation, encryption, offboarding steps and breach notification are already part of our process. Stricter items, like a specific hosting region, dedicated infrastructure or particular audit evidence, are agreed in writing. We would rather commit to what we can genuinely meet than sign up to everything and fall short.