Back to Blog
Privacy & Compliance#enterprise-sales#case-study#NDPR#privacy-by-design#Nigeria#B2B

How Privacy-First Design Won Us a ₦20M Enterprise Contract

Ekfix TeamVerified Feb 19, 2086

When our prospect's legal team asked for our Data Protection Impact Assessment, we had one. Our competitor didn't. That's the whole story—except it isn't, because building to this point took eight months of deliberate work.

Privacy & ComplianceHow Privacy-First Design WonUs a ₦20M Enterprise ContractEkfix

Disclaimer

This article is for educational purposes only and does not constitute legal, financial, or professional advice. Compliance requirements vary by industry and jurisdiction. Consult a qualified professional for guidance specific to your organisation. Information was accurate at the time of writing — verify current regulations with the relevant authorities.

How Privacy-First Design Won Us a ₦20M Enterprise Contract

There is a precise moment in enterprise procurement when privacy-first companies win and everyone else loses. It happens when the buyer's legal or IT team sends a vendor questionnaire and waits for the response.

This is the story of one of those moments, what we had built over the previous eight months that made it winnable, and what you need to replicate the result.


The Procurement Background

The client was a financial services group with approximately 800 employees, operating consumer and business lending products. They needed a custom web application to manage loan officer workflows, customer document collection, and credit committee reporting.

Three vendors were shortlisted, including us. Initial presentations were close — our solution was technically strong, our timeline was competitive, and our pricing was mid-range.

Then the client's legal team entered the procurement process.


The Questionnaire That Changed Everything

The legal team sent a 47-question vendor security and data governance assessment. Questions included:

  • Do you have a documented Data Protection Impact Assessment for similar projects?
  • What is your Data Protection Officer's name and contact information?
  • How do you handle data subject access requests from end-users of systems you build?
  • Describe your data breach detection and notification procedures
  • What encryption standards do you apply to data at rest and in transit?
  • Provide your Record of Processing Activities
  • What data residency guarantees can you provide for Nigerian customer data?
  • Describe your access control model for contractor and employee access to client data
  • What is your secure development lifecycle process?

We answered every question with specific, documented responses. We attached our DPIA template. We named our DPO. We provided our breach notification runbook. We described our role-based access control model and our secure development workflow.

One competitor submitted a two-page response with generic statements. The third did not respond at all, citing "internal policy review."

A week after submission, the client's procurement manager called to let us know we had been selected. He said: "Your documentation was complete. The other responses made it clear they hadn't actually built any of this, which means we'd have had to build it alongside them. That's not a risk we're willing to take for a system that will hold customer financial data."


What We Had Actually Built

The questionnaire responses were not invented for the occasion. They were pulling from real systems and documentation we had built for a different reason: because we believed it was the right way to operate.

Here is specifically what existed:

A Maintained Data Protection Impact Assessment Template

We had built a DPIA template through a project the previous year that involved processing medical records. The process of working through a DPIA — identifying data flows, risk scenarios, mitigations, and residual risks — taught us to think about data architecture differently.

For the financial services pitch, we adapted this template to reflect the specific data categories in their system (KYC documents, financial history, credit decisions) and the specific risks in their context (insider access, document leakage, credit committee data exposure).

This took four hours to adapt. Without the base template, it would have taken four days and would not have been as confident or specific.

A Named DPO on Retainer

We work with a licensed Data Protection Compliance Organisation for our DPO function. For approximately ₦600,000 per year, we have a qualified Data Protection Officer who monitors regulatory changes, assists with DPIA reviews, and provides documentation we can produce in procurement.

This is not an expense — it is an enterprise sales asset. On this contract alone, it returned 33x its cost.

Role-Based Access Control as Standard Practice

We do not build applications where administrator credentials give access to all data. Our standard development practice includes:

  • Separate roles for different user types with explicitly defined data access
  • Audit logging on every data access event, not just write events
  • Automatic session expiration
  • Two-factor authentication for any account with elevated data access

These are not extras we charged for. They are how we build. The financial services client's questionnaire asked about all of them, and we could say "yes, this is our standard — here is how we implement it" rather than "yes, we can add this."

A Breach Response Playbook

We had written a breach notification procedure after attending an NDPC workshop two years earlier. It covered detection, internal escalation, evidence preservation, notification drafting, and regulatory notification to the NDPC within the required 72 hours.

We had tested this procedure on a simulated scenario (not a real incident) with a previous client as part of their onboarding. The test surfaced three gaps we fixed. The resulting procedure is detailed enough that a junior team member could execute it without escalation for clear-cut cases.

Producing this in the questionnaire response — not as a document we would create, but as a document that existed — was different in kind from anything the other vendors could offer.


What the Contract Actually Required

Because we had all of this already, the contract negotiation on data governance was short. The client's legal team reviewed our documentation and requested three additions:

  1. A data retention schedule specific to their data categories
  2. Explicit contractual language about data residency (Nigerian servers or approved cloud regions)
  3. A right to audit our data handling practices associated with their system

All three were reasonable. The first two took one afternoon to produce. The third was a clause we accepted — we had nothing to hide.

The competitor using generic privacy documentation would have faced months of negotiation to define all of this from scratch. We were ready to sign within 10 days of legal review starting.


The Replicable Lessons

The specific contract is not what matters. What matters is that privacy-first infrastructure is a commercial asset with a direct return, and the investment required to build it is much smaller than the revenue it unlocks.

The investment:

  • 8 months of building, documenting, and maintaining data governance practices
  • ₦600,000/year DPO retainer
  • Approximately 40 developer-hours worth of access control and audit logging in our standard application template
  • Time to write and test a breach response playbook (approximately 24 hours, once)

The return from this single contract: ₦20,000,000

The ongoing return: Every enterprise opportunity we enter, we are competitive on privacy documentation from day one. We have won two subsequent enterprise contracts where privacy documentation was a differentiating factor. Competitors who cannot produce equivalent documentation are disqualified before the pricing conversation happens.


What You Should Build Next

If you are a software company or technology services business and you want to be in this position, here is the priority order:

  1. Build your DPIA template. Work through one real DPIA for a current or past project — even if the project is already built. The discipline of identifying data flows and risks is as valuable as the output.

  2. Engage a licensed DPCO. DPO-as-a-service is available in Nigeria for a fraction of what a full-time hire would cost. The documentation support they provide is what you will cite in questionnaires.

  3. Standardise access controls and audit logging. Make role-based access control and comprehensive audit logging part of your default architecture, not an optional add-on. You will charge for the time, but you will no longer need to explain why you're adding cost for basic security.

  4. Write a breach response playbook. It does not need to be long. It needs to be specific enough to execute. Test it once on a simulation.

The financial services group that selected us was not buying privacy compliance from us. They were buying confidence that we would not create a regulatory or reputational problem for them. Privacy-first design was the evidence we could provide that confidence.

That is a sellable product in every enterprise market, and almost nobody is selling it well.


Related Articles