Secure Software Development: The Security Questions to Ask Before You Hire a Development Company
Secure software development from the buyer's side: what to ask a development company about access, code, test data, logins, backups and handover.
Secure software development starts before the first line of code, with the company you hire. Your vendor will hold access to your servers, copies of your data and most of the working knowledge of your code; ask the right questions before you sign and a leak, a lockout or a messy handover stays a risk on paper, not a bill you pay later.
What should you ask a development company about security?
Quick answer: Ask about seven areas: how they will access your systems, whose account holds the code, what data they test with, how they track the libraries the software depends on, where two-factor sign-in is switched on, when they last tested a backup restore, and what you receive at handover. Ask for answers you can check, not a policy document.
Shortlisting vendors? Put your security questions to us →
What a weak answer costs you
Most security problems in a vendor relationship are not clever attacks. They are ordinary: a shared admin password still working months after a developer left, a copy of live customer data on a laptop for testing, an old library with a published flaw, and the only copy of the code in the vendor’s account. Each one is cheap to prevent when you choose the vendor, and expensive to fix after something goes wrong.
The seven areas to check
- Access to your systems. One named account per person, with only the rights their work needs, removed the day they leave the project. No shared logins. You can ask for the list of who has access at any time.
- The code and where it lives. The repository sits in your company’s account from day one, with the vendor’s engineers added as members. A second engineer reviews every change before it is merged.
- Test data. Development and testing run on made-up or masked data, not a copy of your live customers. If real records are ever needed, you agree which ones, where and for how long.
- Libraries and dependencies. Modern software is built on open-source libraries. Ask how they keep a list of them, how quickly they patch known flaws, and whether that continues after launch.
- Logins and two-factor sign-in. Two-factor sign-in on the code host, the cloud console, the app store accounts and email. For your users: sensible password rules, sessions that expire, and roles so each person sees only what their job needs.
- Backups and recovery. Who runs backups, how often, where copies are kept and when a restore was last tested. A backup nobody has restored is a hope, not a plan.
- Handover. Code, documentation, credentials and set-up instructions, with every admin account in your name. Another team should be able to pick the work up from what you receive.
Want a reference to compare answers against? NIST’s Secure Software Development Framework (SSDF) groups good practice into four areas: preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities. You don’t need a vendor to quote it. You need specific answers.
The secure software development checklist for buyers
Send the “Ask” column to every company on your shortlist and compare the replies side by side.
| Area | Ask | A good answer | A warning sign |
|---|---|---|---|
| Access | Who will access our systems, and how? | Named accounts, least rights, removed on exit, list on request | One shared admin login, or “we need full access” |
| Code ownership | Whose account holds the repository, and when do the code and IP become ours? | Your account from day one; the contract states when the code and IP pass to you | Their account, “transferred at the end” |
| Code review | Who checks code before it ships? | A second engineer or tech lead reviews every change, and QA is separate from development | The developer who wrote it is the only one who tests it |
| Test data | What data will you build and test with? | Made-up or masked data; real records only by written agreement | A copy of live data “to make it realistic” |
| Dependencies | How do you track and patch libraries? | A list of what is used, alerts for known flaws, patching agreed in the support plan | “We update when something breaks” |
| Logins and 2FA | Where is two-factor sign-in on? | Code host, cloud, app stores and email, plus roles for your users | Passwords shared in chats or spreadsheets |
| Keys and secrets | Where do API keys and passwords live? | In a secrets store or the server settings, never in the code | Keys committed to the repository |
| Backups | When did you last test a restore? | A date, and what was restored | “Backups are automatic,” with no restore tested |
| Personal data | Which data law applies to our users, and where will the data be stored? | Named for your users, such as UAE PDPL, Saudi PDPL or GDPR, with the hosting region agreed | “That’s your side” |
| Penetration test | For payments, health or ID data: is an independent test planned before launch? | Yes, planned and budgeted in the first estimate | Planned for “after launch”, or never |
| Handover | What exactly do we receive at the end? | Code, documentation, credentials, set-up instructions and accounts in your name | A zip file and a final invoice |
What this means for you: a short list of specific answers (names, dates, accounts) tells you more than a long security policy. A vendor that can’t say when it last tested a restore, or wants your code in its own account, has already answered the question that matters. Security is one part of a wider choice: our scorecard for choosing a software development company in Dubai covers portfolio, team, support and references.
When their developers join your team
If you add developers to your own team rather than handing over a project, the same rules apply from your side. They work in your accounts, on your code host and inside your access rules. You decide what each person can reach, and access ends on their last day. With staff augmentation in the UAE, you also choose who joins.
Send us the checklist with your brief. Tell us what you are building and which of your systems we would touch. We answer every row for your project before any access is granted.
Put your security questions to us →
Buying for a larger organisation? Request the company profile for your procurement file, and we’ll send it to you.
Put your security questions to us
We have built software for more than 100 clients since 2014, across the UAE, Saudi Arabia, Qatar, Kuwait, the USA and Canada. Our headquarters is at Dubai Digital Park in Dubai Silicon Oasis, with offices in Houston and Alexandria. Sparx is a pharmacy app we built, where users upload prescriptions for a pharmacist to review. Talk to the team that built it: book a meeting.
Two of the ways we work answer the checklist’s hardest rows. CTO oversight: every project is supervised by senior technical leadership, so a named senior person owns decisions on access, data and architecture. Independent QA: separate from development, so the person testing the work did not write it, and the cases a builder may not think to try get tested, such as the wrong role opening the wrong record or a session that should have expired.
If you are planning custom software development in Dubai or an app, bring this checklist to the first conversation and score our answers with the rest.
Put your security questions to us → We ask about your goal, what you use today, your timing and who else should be involved. You leave with clear next steps. We reply by email first and set up a call only if you want one. Asking commits you to nothing, and we sign an NDA first if you ask.
Frequently asked questions
Who owns the code?
Your company should, and the contract should say when. Ask for the repository and app store accounts to be in your company's name from day one. With us, they can be yours from the start, and the code and IP pass to you once the project is completed and paid.
Should a development company have access to our live systems?
Only to what the work needs, through named accounts you can switch off. Most building and testing happens in separate development and test environments. Access to live systems is for releases and support, agreed in advance and logged wherever your systems allow it.
Can developers test with our real customer data?
Avoid it. Made-up or masked data covers almost every test. If a problem only shows up with real records, agree exactly which ones, where they will be kept, who can see them and when they are deleted, before anything is copied.
Do we need a penetration test?
If the app holds payments, health records or identity documents, plan an independent test by a specialist firm before launch, and budget for it in the first estimate rather than at the end. For simpler apps, code review, independent QA and up-to-date libraries are the baseline.
How do we check that the answers are true?
Ask for things you can see: the member list on your repository, the two-factor setting on the code host, the date of the last restore test and a sample of the library report. During the build, ask for the access list again at each milestone. A vendor that works this way can produce all of it the same day.
