Before you sign a contract with any software developer or agency, you should be asking specific, direct questions about how they will protect your business and customer data — because the answers separate a developer who treats security as a checklist item from one who treats it as an afterthought. This matters more than most Nigerian business owners realize when commissioning custom software: a data breach at a healthcare platform, a fintech tool, or even a simple customer database can cost far more in reputation and legal exposure than the entire software project was worth.
We take this seriously at Harzotech because of the kind of systems we build — patient data for a multi-specialty healthcare group like Beaconhill Smile Group, investor and property data for a diaspora real estate platform like Zithelo, and operational data for corporate ERP implementations through partners like R3 Consulting Ltd. Sensitive data is not a special case in our projects; it is the default.
Questions to Ask Before You Sign
How will data be encrypted, both in transit and at rest?
Data moving between your users' devices and your servers should be encrypted (HTTPS/TLS is the baseline expectation, not an upgrade). Data stored in your database should also be encrypted, particularly for sensitive fields like passwords, payment details, or health records. If a developer cannot answer this clearly, that is a red flag.
Where will the data physically be hosted?
Under Nigeria's NDPR framework, where and how personal data is stored and processed carries legal implications. Ask which cloud provider or hosting environment will be used, and whether that provider has adequate security certifications.
Who has access to production data, and how is that access controlled?
Not every developer on a project needs access to live customer data. Ask how access is restricted, whether access is logged, and what happens when someone leaves the project team.
How are passwords and sensitive credentials stored?
Passwords should never be stored in plain text — they should be hashed using a modern algorithm. If a developer says they store passwords "encrypted" rather than "hashed," ask a follow-up question; this is a common point of confusion that indicates weaker security practice.
What is the backup and disaster recovery plan?
Ask how often backups run, where they are stored, and how quickly the system could be restored if something went wrong. A business that loses customer or transaction data with no backup has no recovery path.
How is the software tested for vulnerabilities?
Ask whether the developer runs any security testing — even basic vulnerability scanning — before launch, and whether dependencies (third-party code libraries) are kept updated to patch known security issues.
What happens in the event of a breach?
A serious developer should have a clear answer here: how they would detect a breach, how quickly they would notify you, and what remediation looks like. "That won't happen" is not an acceptable answer.
Is the developer NDPR-aware for Nigerian data protection compliance?
If your software collects personal data from Nigerian users — which most customer-facing software does — your developer should understand the basics of NDPR compliance: lawful basis for data collection, user consent, and data subject rights.
What happens to the data if the project or relationship ends?
Get clarity upfront on data portability — can you export a full, usable copy of your data if you switch developers or discontinue the project? A vendor who cannot answer this clearly may be building your system in a way that quietly locks your data into a format only they can work with.
Red Flags Worth Walking Away From
- A developer who cannot explain their security practices in plain language
- No mention of backups or disaster recovery in the proposal
- Reluctance to put data handling and security responsibilities in the contract
- No plan for what happens to your data or codebase if the relationship ends
Why This Matters More for Certain Industries
Some sectors carry higher stakes than others. Healthcare platforms handling patient records, fintech and payment tools handling financial data, and any system storing personal identification details all carry legal and reputational exposure well beyond the average business tool. If you operate in one of these spaces, it is worth asking your developer for concrete examples of how they have handled data protection for similarly sensitive systems before, rather than accepting general reassurances. A developer with genuine experience in regulated or sensitive-data environments will have specific, detailed answers ready — vague answers under direct questioning are themselves useful information.
It is also worth remembering that data security is not a one-time achievement at launch. New vulnerabilities are discovered in software dependencies constantly, and a system that was secure at launch can become vulnerable over time if it is not actively maintained. This is exactly why an ongoing maintenance arrangement, not just a one-off build, matters for any software handling meaningful business or customer data.
Security Is Not a Line Item, It Is a Default
The businesses that get burned by data security failures are rarely the ones who asked too many questions upfront — they are the ones who assumed security was handled because nobody raised it. Whether you are building a customer portal, an internal tool, or a full custom software platform, data security should be part of the initial scoping conversation, not something bolted on after launch.
If you are evaluating a custom software project and want a partner who treats data protection as a baseline requirement rather than an upsell, book a consultation with Harzotech.