If you run a business today, you run software. Your website takes orders, your app holds customer phone numbers and card details, your dashboard shows who owes you money and who you owe. All of that lives on servers you probably cannot see, protected by decisions you may not have made yourself. And here is the uncomfortable truth: the people trying to get into that system are not thinking of it as a technical problem. They are thinking of it as a business opportunity. Their business is taking what belongs to you.
For a long time, security was treated as something the developers would "handle later," a box to tick before launch and then forget. That mindset has cost Nigerian and African businesses real money, real customers, and sometimes their entire reputation. A payment startup in Lagos, a logistics firm in Nairobi, a small shop selling from someone's living room in Accra: the size of the company does not decide whether it gets attacked. The value of its data does. And attackers have learned that smaller businesses, the ones without a dedicated security person, are often the softest targets.
This article is written for the business owner and decision-maker, not the security engineer. You do not need to write code to understand where your risk lives, ask the right questions, and hold your team or vendor accountable. Think of it as the conversation a security-minded engineer would have with you over coffee, in plain business language, so you can spend a little smarter and sleep a little easier.
Security Is a Business Problem, Not Just a Technical One
The single most expensive mistake in this field is believing that security is the IT department's job and nobody else's. It is not. Security is a decision about how much risk your business is willing to carry, and that is a leadership decision, the same way you decide how much insurance to buy or how much cash to keep in reserve.
Here is why it lands on your desk and not just the developer's. When a breach happens, the developer does not stand in front of your customers and explain why their bank details leaked. You do. The developer does not negotiate with the regulator or the journalist calling for comment. You do. The consequences of poor security are business consequences: lost revenue, lost trust, legal exposure, and time your team spends cleaning up a mess instead of growing the company. And there is a money angle most people miss: good security is cheaper than bad security. Building things properly the first time costs a fraction of what it costs to recover from an incident and retrofit protections onto a system that was never designed for them. Businesses that treat security as an afterthought almost always pay more in the end. They just pay it later and all at once.
The Real Cost of a Breach
When people imagine a breach, they picture a hacker in a dark room and some money disappearing from an account. The reality is broader and, frankly, more painful. The damage comes in three waves, and the second and third usually hurt more than the first.
The Money You Can Count
The first wave is direct financial loss, and it is the easiest to measure: stolen funds, fraudulent transactions, ransom demands to unlock your own systems, and the emergency cost of bringing in outside help at short notice. In markets where mobile money and instant transfers are woven into daily commerce, this wave moves fast. A compromised account or a weakness in how transactions are authorised can drain value in minutes, and once money has passed through several wallets, recovering it is difficult and often impossible.
The Trust You Cannot Rebuild Overnight
The second wave is the loss of trust, and this is where the deep damage sits. Customers hand you their data because they believe you will look after it. The moment that belief cracks, they leave, and they tell others why. A business can survive losing money. Surviving the loss of its customers' confidence is much harder. You spent years building a reputation; a single well-publicised breach can spend it for you in a weekend.
The Legal and Regulatory Weight
The third wave is legal and regulatory. Data protection is now law, not a courtesy. When personal data is exposed, you may be obligated to notify the people affected and the relevant authority, and you may face penalties for failing to protect that data in the first place. We will return to Nigeria's data protection duties later, but the headline is simple: a breach is no longer just a technical failure, it is potentially a compliance failure with real consequences attached.
The cheapest breach to recover from is the one that never happened. Every naira spent on prevention buys down a much larger, much messier bill you would otherwise pay in a panic, at the worst possible time, in front of an audience.
The Common Risk Categories in Plain Language
Security professionals talk about a well-known list of the most common and dangerous web application risks, often called the OWASP Top Ten. You do not need to memorise it, but understanding the categories in plain language helps you ask sharper questions. Think of these as the doors and windows attackers try first.
Injection and Broken Authentication
Injection happens when your application blindly trusts whatever a user types and passes it straight to a database or command without checking it. A form field that should hold a name might instead hold a hidden instruction, and a careless system will obey. It is like a security guard who follows any note handed to him, even one that says "let this person into the vault." Broken authentication is a close cousin: when the process that confirms who a user is can be tricked, guessed, or bypassed, attackers can impersonate legitimate users or hijack their sessions. This is the digital equivalent of a lock that opens with a firm push.
Exposed Data, Misconfiguration, and Old Components
Sensitive data such as passwords, card details, and identity numbers needs special handling. When it is stored or sent without proper protection, anyone who intercepts it can read it, like writing your safe combination on a sticky note pressed to the safe door. Misconfiguration is one of the most common and most preventable risks: default passwords never changed, admin panels left open to the public internet, error messages that reveal too much. Nothing was "hacked" in the dramatic sense; a door was simply left unlocked. And because modern applications are built on top of other people's software, running outdated components means inheriting every known weakness in them. Attackers actively scan the internet for old, vulnerable versions, because the flaws are already public and the exploits already written.
Broken Access Control
Access control decides who is allowed to do what. When it is broken, an ordinary user might view another user's records, or reach an admin function they should never touch, simply by changing a number in a web address. It is the difference between a hotel key that opens only your room and one that quietly opens every room on the floor.
Authentication and Passwords Done Right
Since broken authentication is such a common weak point, it deserves its own attention. This is the front door of your application, and getting it right delivers an enormous return for a modest effort. Start with how passwords are handled. Your system should never store passwords as plain readable text. If someone reaches your database and finds a neat list of every customer's password, you have handed them the keys not just to your app but to every other service where those customers reused the same password. Passwords should be stored using a strong one-way scrambling process, so that even you cannot read them, only verify that the right one was entered.
Beyond storage, the practices that matter most are straightforward:
- Encourage strong, unique passwords. Length beats complexity. A long passphrase is both harder to crack and easier to remember than a short jumble of symbols that ends up written on a desk.
- Turn on multi-factor authentication. This means a password plus a second proof, such as a code from a phone app. Even if an attacker steals a password, that second factor stops them cold. For anything that touches money or sensitive data, treat this as non-negotiable.
- Limit repeated login attempts. Hundreds of password tries in a minute is not a forgetful customer, it is a machine guessing. Your system should slow down or block that automatically.
- Handle resets and sessions carefully. The "forgot password" flow is a favourite target; it must verify identity and expire reset links quickly. And do not let sessions stay open forever, especially on shared devices. An abandoned session on an internet café computer is a gift to the next person who sits down.
One point aimed squarely at our region: mobile money and instant transfer fraud often begins with social engineering, not clever code. Attackers phone your staff or customers pretending to be support and talk them into handing over a code or approving a transaction. No amount of technical security fixes a person who has been convinced to open the door. Train your team to recognise these tricks, and never let a genuine process depend on a customer reading out a one-time code to anyone.
Encryption and HTTPS: Protecting Data in Motion and at Rest
Encryption scrambles data so that only someone with the right key can read it. If an attacker intercepts encrypted data, they get gibberish. It is one of the most powerful tools you have, and much of it is now standard and inexpensive. There are two moments where data is vulnerable, and encryption protects both.
Data in Motion: Why HTTPS Is Not Optional
Every time information travels between your customer's browser and your server, it passes through networks you do not control, including public Wi-Fi in cafés, airports, and shared offices. Without protection, anyone on that network can read it. HTTPS, the secure version of the web protocol shown by the padlock in the browser, encrypts that traffic so it cannot be read in transit. There is no longer any excuse for a business site to run without it. Certificates are widely available at no cost, browsers now warn visitors when a site is not secure, and customers increasingly notice. If any part of your service, especially a login or payment page, still runs on plain unencrypted connections, that is an urgent fix, not a nice-to-have.
Data at Rest: Protecting What Sits in Storage
Data at rest is the information sitting in your databases and backups when nobody is actively using it. Sensitive fields such as identity numbers, financial details, and personal records should be encrypted in storage too, so that even someone who gets hold of the raw database files cannot simply read everything. This matters especially in shared hosting environments, common for smaller businesses, where you do not fully control the underlying server and cannot always be certain who else has access to the machine.
Input Validation: Never Trust What Comes From Outside
There is a principle underneath a huge share of security work: never trust input from the outside world. Every piece of data that arrives from a user, a form, a file upload, or another system should be treated as potentially hostile until proven safe. This is not paranoia, it is professionalism. Input validation is the discipline of checking that incoming data is what you expect before you do anything with it. An email field should contain an email. A quantity field should hold a sensible number, not a negative value or a hidden command. When your application enforces these rules strictly, it closes the door on entire categories of attack, including the injection risks we discussed earlier.
What good validation looks like, in plain terms:
- Check on the server, not just in the browser. Checks that happen only in the user's browser can be bypassed in seconds. The real gatekeeping must happen on your server, where the attacker cannot reach it.
- Prefer allow-lists over block-lists. Rather than guessing every bad thing someone might enter, define exactly what is acceptable and reject everything else. It is easier to describe a valid phone number than to list every way someone could misuse the field.
- Handle file uploads with extra care. Uploaded files are a classic hiding place for malicious content. Limit the types and sizes you accept, and never let uploaded files run as programs on your server.
Keep Software Patched, and Keep Good Backups
This next pair is the least glamorous work in security and among the most important. Software ages badly. Flaws are discovered in even the best-built components over time, and when they are found, the fix is usually published quickly. But a published fix only protects you if you actually apply it. The gap between "a fix exists" and "we installed it" is exactly where attackers live. Because so many known weaknesses are public, attackers do not need to be sophisticated: they run automated tools that scan the internet for systems still running old versions, then walk through the front door the update was meant to close.
For a growing business without a dedicated security team, the practical answer is a simple, boring routine:
- Keep an inventory. You cannot update what you do not know you have. Maintain a list of the software, plugins, and components your systems depend on, and remove the ones you no longer use.
- Schedule regular updates. Treat patching as routine maintenance, like servicing a vehicle, not something you do only when something breaks.
- Prioritise the urgent ones. Some flaws are minor, others are actively being exploited. Make sure someone is watching which updates cannot wait.
Even so, no defence is perfect. Given enough time and motivation, defences can fail, and even the best-run companies eventually face an incident, whether malicious, accidental, or a simple hardware failure. What separates a bad day from a catastrophe is whether you can recover. That is what backups are for. Ransomware, where attackers lock up your data and demand payment to release it, has become common precisely because so many businesses cannot recover on their own and feel forced to pay. A business with solid, tested backups can often say no, restore its systems, and move on.
- Keep more than one copy, in more than one place. A backup sitting on the same server as your live data disappears along with it if that server is compromised. Keep at least one copy somewhere separate.
- Automate it and protect it. Backups that depend on someone remembering to run them get forgotten. A backup is also a full copy of your sensitive data, so it needs the same encryption and tight access as the original.
- Test that they actually work. A backup you have never tried to restore is a guess, not a safety net. Practise restoring, so that on the day you need it, you know it works and how long it takes.
Least Privilege, Monitoring, and Third-Party Risk
Give People and Systems Only What They Need
One of the quietest and most effective principles is least privilege: every person, and every part of your system, should have access to the minimum they need to do their job, and nothing more. The junior staff member handling enquiries does not need the power to delete the entire database. Why does this matter? Because accounts get compromised, and when they do, the damage is limited to whatever that account was allowed to do. In practice this means giving each staff member their own account rather than sharing logins, granting admin powers only to the few who truly need them, and removing access promptly when someone changes role or leaves. That last point is a common gap in small, fast-moving teams: former staff and old contractors whose access was never switched off remain live doors long after they have gone.
You Cannot Respond to What You Cannot See
Monitoring means keeping records of important events, such as logins, failed login attempts, changes to sensitive data, and administrative actions, and having someone or something watch those records for signs of trouble. The goal is early warning. Most serious breaches are not smash-and-grab; attackers often linger inside a system for a long time, quietly exploring, before they act. You do not need a fancy operations centre to benefit. Keep logs of key activity, set alerts for the unusual, such as a login from an unexpected country or a large data export at three in the morning, and have a simple plan for who to call and what to shut down when the alarm rings. Store those logs somewhere attackers cannot easily erase, because covering their tracks is often the first thing they try.
Your Security Is Only as Strong as Your Weakest Vendor
Very few businesses build everything themselves. You use a payment gateway, a hosting provider, an email service, perhaps a few plugins and integrations. Every one is a relationship of trust, and also a potential path into your business. If a service you depend on is breached, attackers may reach your data through it, no matter how carefully you guarded your own front door. Choose reputable providers over the cheapest option with no track record, because cheap can become very expensive. Know which third parties hold your customers' data and what they are permitted to do with it, and give each integration only the permissions it genuinely needs. A tool that only needs to read data should not be able to change or delete it.
Nigeria's Data Protection Duties: The NDPA in Plain Terms
For a long time, businesses in Nigeria could treat data protection as a matter of goodwill. That era is over. The Nigeria Data Protection Act, commonly referred to as the NDPA, has put data protection on a legal footing, and it applies to organisations that handle the personal data of people in Nigeria. If you collect names, phone numbers, email addresses, identity details, or payment information, and almost every business does, then this concerns you. This is not legal advice, and you should speak to a qualified professional about your specific obligations. But in general terms, the spirit of the law lines up closely with the good security practices we have already discussed.
- Collect only what you need. Gathering personal data you have no real use for is a liability, not an asset. The less sensitive data you hold, the less you can lose.
- Be clear about why you collect it. People have a right to understand what you are doing with their information and to expect you not to quietly repurpose it for something they never agreed to.
- Protect it properly. The law expects reasonable measures to keep personal data secure. The encryption, access control, and monitoring above are exactly the kind of measures that show you take this duty seriously.
- Respect people's rights and prepare for a breach. Individuals have rights over the information you hold about them. And if personal data is exposed, you may have to notify the relevant authority and the affected people within a certain timeframe. Knowing this in advance, with a plan, beats scrambling in the middle of a crisis.
The broader point is that compliance and good security are not two separate projects competing for your attention. They are largely the same work seen from two angles. A business that protects its customers' data well is, for the most part, meeting its data protection duties too.
A Practical Security Checklist for a Growing Business
All of this can feel like a lot, especially for a lean team wearing many hats. So here is a grounded checklist you can work through, or hand to your technical team or vendor and ask them to confirm point by point. You do not need to solve everything this week. You need to start, and to keep going.
- Turn on HTTPS everywhere. Every page, especially logins and payments, should show the padlock. If it does not, fix that first.
- Enable multi-factor authentication on every account that touches money, customer data, or system administration.
- Store passwords securely using strong one-way scrambling, and confirm nobody is keeping them as readable text anywhere.
- Give each person their own account with only the access they need, and remove access the moment someone leaves or changes role.
- Validate all input on the server so hostile data cannot slip through your forms and uploads.
- Keep your software updated on a regular schedule, and remove plugins and components you no longer use.
- Back up your data automatically to a separate location, protect those backups, and test that you can restore from them.
- Encrypt sensitive data at rest, not just in transit, especially on shared hosting.
- Keep logs and set alerts for unusual activity, and know who responds when an alert fires.
- Review your third parties and understand who holds your customers' data and what access each one has.
- Train your people to recognise social engineering and fraud, because the human is often the real target.
- Understand your NDPA duties, collect only the data you need, and write down a simple incident plan so a bad day is met with a plan, not panic.
Work through that list honestly, and you will already be ahead of a large share of businesses in the region. Security is not a destination you arrive at once and forget. It is a habit, a set of small disciplines repeated over time. The goal is not perfection, which no one achieves. The goal is to be a harder target than the attacker expected, and to recover gracefully on the day something does go wrong.
Building It Right From the Start
If there is one idea to carry away from all this, it is that security is not a feature you bolt on at the end. It is a way of building, present in every decision from the first line of code to how your team handles a password reset over the phone. Retrofitting security onto a system that was never designed for it is expensive, awkward, and never quite as strong as doing it right from the beginning. The businesses that thrive are the ones that treat protecting their customers as part of serving them, not a burden separate from it.
You do not have to carry this alone, and you should not try to. Most growing businesses do not have a dedicated security engineer, and they do not need one, provided the people building and maintaining their systems take these principles seriously and can explain their choices in language you understand. That is the standard to hold your team or technology partner to: not just "does it work," but "is it safe, and can you show me why." At Rahmontech Enterprises, we build software with these questions baked in from the first conversation, because we have seen what it costs African businesses when security is treated as an afterthought. Your customers trusted you with their data. Building securely is simply how you keep faith with that trust.
