Your data, and who can read it
Security isn't a feature we add at the end. It's decided in the first architecture meeting, and it's the reason a system still holds up three years later. Here is exactly how we handle what you trust us with — in plain language, with no hedging.
The short version
Most security pages are a wall of acronyms designed to sound impressive. These are the four things that actually decide whether your data is safe, stated so you can hold us to them.
Not to us, and not to whoever hosts it. You can export all of it, in a usable format, at any time, without asking permission or paying a fee.
Our access is for keeping the system running, not for browsing what's inside it. Access is named, logged, time-limited and revoked when the work ends.
Your records are not a product. They are not passed to advertisers, brokers, partners or AI training sets. There is no small print reversing this.
Not from a customer, not from the news. We tell you what happened, what was affected and what we're doing, within 24 hours of confirming it.
Photo — Christina Morillo
The engineering
Every system we build ships with all of this. It isn't an upgrade tier.
Every page, form and API call travels over TLS. HTTP requests are redirected to HTTPS before anything is sent, and HSTS tells the browser never to try the insecure route again. On a shared office network or public wifi, what passes between your staff and the server is unreadable to anyone watching the connection.
Databases and file storage sit on encrypted volumes, so the raw disk is meaningless without the keys. Sensitive columns — identity numbers, bank details, health notes — get a second layer of application-level encryption, meaning even a full database dump gives an attacker ciphertext rather than records.
Passwords are never stored. What's stored is a one-way hash produced with bcrypt or Argon2 and a unique salt per user. There is no lookup, no decryption and no master list. If your database were stolen tomorrow, the thief could not sign in as your users, and we could not tell you a single password even if you asked.
Every database query uses prepared statements with bound parameters, so user input is never mixed into SQL as text. That single discipline removes the attack behind a large share of real-world breaches. Output is escaped on the way out too, which closes cross-site scripting, and forms carry CSRF tokens so nobody can act as your logged-in staff.
Every account gets the narrowest permissions that let it do its job, and nothing more. Staff see only the records their role requires. No shared logins, so every action traces to a named person. Admin access uses multi-factor authentication, and the application's own database user cannot drop tables or read what it doesn't need.
Logins, failed attempts, permission changes, exports and deletions are all written to an audit trail with a user, a timestamp and an address. Nothing important happens invisibly. When a client asks who changed a record last March, there's an answer rather than a guess — and that trail is also what makes an investigation possible if it's ever needed.
Automated daily backups, encrypted before they leave the server, stored off-site and in a second region. A backup nobody has restored is a rumour, so we run a real restore on a schedule and time it. You get told the retention period and the recovery target in writing, not vaguely reassured that "backups exist".
The safest record is the one that was never collected. We push back on forms that ask for data you have no use for, because every extra field is a liability the day something goes wrong. Retention periods are agreed up front and old records are deleted on schedule rather than accumulating forever.
Most breaches don't use a clever new attack. They use a known hole in an old library that nobody patched. Dependencies are monitored for published vulnerabilities and updated on a schedule, secrets are kept out of the code and out of version history, and code is reviewed by a second person before it reaches production.
Photo — Mikhail Nilov
Where the law sits
If you hold personal data on Nigerians, the Nigeria Data Protection Act 2023 applies to you, and the regulator is the Nigeria Data Protection Commission. The obligations it places on you don't move to your developer — you remain the data controller. What we can do is build a system where meeting them is straightforward instead of impossible.
So the systems we deliver come with the practical machinery the Act expects: a lawful basis recorded for what you collect, consent captured with a timestamp rather than assumed, a way to export or delete an individual's records when they ask, breach detection quick enough to meet notification deadlines, and access controls that can be evidenced rather than described.
The same design also travels. Clients serving customers in Europe or the UK inherit the structure GDPR asks for, because the underlying principles — minimise, secure, be able to prove it — are the same ones.
We're engineers, not lawyers. We build to these standards and we'll tell you where your setup falls short, but a compliance opinion has to come from a qualified data protection adviser. We'll say so rather than let you assume you're covered.
While we're working together
Each engineer gets their own account with their own permissions. Nobody logs in as "admin". Every action in your system traces to a person, including ours.
Development happens against copies with the sensitive fields scrambled. Live access is requested, granted for a window, logged, and withdrawn afterwards — not left standing because it's convenient.
At handover, every credential is rotated and transferred into your name and our accounts are removed. You can verify it yourself. Nobody should be able to reach your system years later because an old account was forgotten.
We sign an NDA before seeing anything sensitive, and we'll sign yours rather than insist on ours. Your data, your code and your commercial information stay between us.
You're told which external services touch your data — hosting, email delivery, payments — and why each one is there. Nothing new gets added to that list without asking you first.
Who to call, what gets isolated, how it's contained and who must be notified — decided before anything happens rather than improvised at 2am. If we discover something, you know within 24 hours.
Found something?
If you believe you've found a vulnerability in something we built, report it to security@giftdevinnovation.com. We'll acknowledge it within one business day and keep you updated until it's closed. We don't threaten people who report problems in good faith — that reaction is how small issues become public ones.
We'll review what you have, tell you plainly what's exposed, and price the fix. Even if you don't hire us for the repair, you'll know where you stand.