Plain-English notes on Nigerian law

On paper, building a good vendor assessment process for privacy and security seems easy enough. You know what you need to do. Figure out who your vendors are, check them out, understand what risks they bring, manage those risks, and keep track of what you're going to do about it. Most organisations can describe exactly what "good" looks like.

But actually making that work day to day, especially if you're in a big global company that operates across dozens of countries, is a whole different story.

The problem is that scale changes everything.

When you're dealing with an organisation that's grown through acquisitions, operates under different legal systems, and has business units that do things their own way, your vendor ecosystem becomes a mess. It's not unusual to see fifty or sixty thousand vendors on the books, everything from massive strategic partners to the local catering company that no one in head office has ever heard of. Different regions have different procurement habits. Different legal teams have different standards. Some privacy and security teams know what they're doing; others are still figuring it out. What starts as a sensible governance project quickly turns into an organisational nightmare.

Where most organisations get this wrong

One of the biggest mistakes I see is treating privacy and security like they have nothing to do with each other. The privacy team looks at legal obligations and data handling. The security team looks at technical controls and infrastructure. Each team does their job. But they almost never do their jobs together. So you end up with overlapping questionnaires, duplicated work, inconsistent conclusions, delayed onboarding, and no single view of how risky a vendor actually is. Vendors get asked the same questions in slightly different ways by different people. Internal teams end up with multiple intake processes, conflicting advice, and no idea what actually matters. Instead of one clear risk picture, you end up with two partial ones. That just doesn't work at scale.

Another problem is how much energy organisations pour into the assessment itself, the questionnaire, the template, the perfect compliance language, while giving almost no thought to what happens after the assessment is done. I have seen this over and over. You ask the obvious questions. How do we flag risks? What does this risk actually mean given how much risk we are willing to take as a company? Who owns this risk? Who is supposed to fix it? What is the timeline? How do we track progress? And too often, there are no good answers. Without those answers, your assessment is just paperwork. It is not actually helping you manage risk. A mature process is not about having a beautiful questionnaire. It is about making sure every risk you find has someone responsible for it, a clear plan, and a way to track whether it is actually being fixed.

And here is another thing that goes wrong all the time. People write assessments for lawyers and regulators, not for the human beings who actually have to fill them out. I once saw a questionnaire that asked vendors, "Do you transfer data to adequate jurisdictions?" That is a perfectly precise legal question. But most vendors have no idea what an "adequate jurisdiction" is. A better question would be, "Do you send data to any of these specific countries?" Same legal outcome, but you will actually get a useful answer. The same thing happens internally. Instead of asking an employee, "Are you transferring personal data?" which most of them cannot answer, ask, "Are you going to upload customer names, email addresses, or employee records into this system?" The person filling out your assessment does not know what you know. If you want good answers, you have to ask good questions.

So what actually works?

First, stop treating privacy and security as separate tracks. You need one way for vendors to come in, one assessment, one process, one onboarding path. Privacy and security should look at the same vendor at the same time, using the same information, following the same workflow. When you do that, onboarding gets faster, duplication disappears, teams actually agree with each other, and you end up with one risk decision instead of two conflicting ones.

Second, make your assessment usable. If people cannot understand it, it is useless. Translate legal concepts into plain language. Ask questions about things people actually know. This one change will improve your data quality more than almost anything else.

Third, automate where it makes sense, but do not pretend automation solves everything. Get out of email and spreadsheets. Use a proper platform to bring vendors in, run assessments, assign actions, track fixes, and keep an audit trail. But automation is not magic. You still need human beings to read between the lines, challenge weak responses, understand context, and make real risk decisions. Your output is only as good as your input. If people give you imperfect data, your fancy automated system will give you imperfect results. Good data is not a nice-to-have. It is a must-have.

Final advice

Do not treat this as a privacy project or a security project. Treat it as an organisational priority. Because it touches everything, procurement, legal, privacy, security, IT, operations, every part of the business that works with vendors. It changes how vendors get onboarded and who makes the decisions. That kind of change needs leadership from the top. Not just the DPO or the CISO. I am talking about executive sponsorship. When the leadership team actually backs this, everything gets easier. Priorities line up. Resistance fades. People actually adopt the new way of working. And real change becomes possible.

You do not build a scalable vendor assessment process by making your questionnaire longer. You build it by integrating your teams, designing for real people, using automation wisely, demanding good data, and getting the whole organisation to take it seriously.

In many organisations, data breach management exists as a policy document that is rarely tested and often poorly understood. Yet under modern data protection law, it is expected to function as a working capability, not paperwork.

Under the Nigeria Data Protection Act, controllers and processors are expected not only to secure personal data but to be able to demonstrate that appropriate safeguards are in place and that they can respond effectively when incidents occur.

A practical breach management system therefore, needs to operate across three connected stages: preparation, response, and post-incident review.

Preparation before anything goes wrong

Effective breach management begins long before any incident occurs. The first requirement is understanding the full scope of data processing within the organisation. This includes knowing what personal data is collected, where it is stored, how it flows across systems, who has access to it, and the purpose for which it is processed.

Without this visibility, it becomes extremely difficult to apply meaningful security controls or respond effectively when something goes wrong.

The law requires that personal data be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical and organisational measures.

Technical measures refer to safeguards such as encryption, access controls, system monitoring, secure configuration, and backup mechanisms. Organisational measures include governance structures, internal policies, staff training, access management procedures, vendor oversight, and clearly defined responsibilities.

The key point is that "appropriate" security is not about applying the highest level of protection in all cases. It is about applying proportionate controls based on risk, including the sensitivity of the data, the scale of processing, and the potential impact on individuals.

However, it is not enough to simply have these controls in place. Controllers and processors must also be able to demonstrate that they are actually applied. This requires documentation, audit trails, training records, risk assessments, and evidence of ongoing monitoring and review. In regulatory terms, if compliance cannot be demonstrated, it is often treated as non-compliance.

Preparation also includes incident readiness. This means having an operational incident response plan, clearly defined escalation paths, designated response teams, and detection capabilities such as system logs, alerts, and monitoring tools. Without these, breaches may go undetected or be detected too late to limit damage.

Detection and response when a breach occurs

A personal data breach refers to any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

Importantly, this definition focuses on actual compromise of personal data. A risk or vulnerability alone is not sufficient. A breach occurs when personal data has actually been affected.

The critical legal trigger is awareness. Once an organisation becomes aware of a breach, its response obligations begin. This makes detection capability essential. If an organisation cannot detect incidents, it cannot comply with its legal duties.

Once a breach is detected, the immediate priority is containment. This may involve isolating affected systems, disabling compromised accounts, revoking access, securing backups, or stopping ongoing data exposure. At this stage, the objective is to prevent further harm.

After containment, the organisation must assess whether a personal data breach has occurred and evaluate the risk to individuals. This assessment must be carried out quickly because notification timelines are strict.

In Nigeria, where notification is required, it must be made to the Nigeria Data Protection Commission under the Nigeria Data Protection Act.

The assessment considers several factors including the type and sensitivity of data involved, the volume of data affected, how easily individuals can be identified, the potential consequences for those individuals, and the severity of the impact.

Processors have a specific obligation at this stage. They must notify the controller of any personal data breach without undue delay. They do not assess risk or decide on notification. That responsibility lies with the controller.

Controllers must then determine whether the breach is likely to result in a risk or a high risk to individuals. Where there is a risk, notification to the NDPC is required. Where there is a high risk, communication to affected individuals may also be required.

All of this must be done within a very short timeframe, which is why breach response cannot be improvised. It must be structured in advance.

Notification and communication obligations

Once a breach meets the threshold for notification, the controller must report it to the NDPC without undue delay and, where feasible, within the prescribed timeframe.

The purpose of notification is not only compliance but oversight. Regulators need visibility into incidents to assess systemic risks and ensure appropriate remediation.

Where the breach is likely to result in a high risk to the rights and freedoms of individuals, those individuals must also be informed. This communication must be clear, practical, and focused on helping individuals understand what happened and what steps they should take.

There are limited exceptions. If the data is rendered unintelligible through measures such as encryption, notification to individuals may not be required. Similarly, if the organisation takes immediate steps to eliminate the risk, communication obligations may be reduced. In cases where identifying individuals is not possible, alternative forms of public communication may be used.

Even where notification is not required, the decision must be documented and capable of justification.

After the breach what happens next is critical

Many organisations treat breach management as complete once notifications are sent. In reality, this is where the most important governance work begins.

Every breach must be fully documented. This includes the timeline of events, the nature of the incident, the data affected, the root cause, the actions taken, and the rationale behind key decisions. These records form part of the organisation's accountability framework and may be reviewed by regulators long after the incident.

This documentation requirement applies not only to breaches that are reported externally, but also to those that are assessed and not reported. In practice, this creates a complete internal record of all incidents and decisions.

After documentation, a structured post-incident review should be conducted. The purpose is not blame but improvement. The organisation should assess how the breach occurred, how quickly it was detected, how effectively it was contained, and whether the response followed expected procedures.

Key questions include whether monitoring systems were effective, whether staff understood their roles, whether escalation processes worked in practice, and what changes are needed to prevent recurrence.

This stage is what transforms breach management from reactive response into continuous improvement.

Data breach management is not a one-time response process. It is a lifecycle that starts with understanding your data, continues through preparedness and detection, is tested during incident response, and is strengthened through post-incident learning.

When done properly, it reflects a mature data protection culture. When done poorly, it exposes organisations not only to regulatory risk, but to operational and reputational damage that is often avoidable.

In the end, effective breach management is not defined by how an organisation reacts to failure, but by how prepared it was before the failure ever occurred.

During a recent data protection training, a simple question was asked that stayed with me long after the session ended. Do people really know who has their personal data?

At first, the answer felt obvious. After all, people usually provide their information directly to organisations themselves. But the more we discussed it, the more complicated the answer became.

Think about something as routine as opening a social media account or filling out an online form. You provide your name, your phone number, your email address, and sometimes even more sensitive information. You know the organisation you gave it to. What is far less clear is what happens next.

Is the data shared with service providers? Is it stored outside the country? Is it analysed by software? Is it transferred to other partners within a business ecosystem? At that point, the question becomes much harder to answer, even for professionals.

For the average individual, it becomes almost impossible to trace where their data is actually going.

This is exactly why transparency is one of the most important principles in data protection. Privacy should never feel like a mystery. People should not have to guess what organisations are doing with their information.

At its core, transparency simply means people should know what data you have about them, what you are doing with it, why you need it and who else may have access to it. Except in very limited situations where the law permits otherwise, there should be no hidden processing of personal data. Organisations should not operate in ways that make individuals feel monitored without their knowledge.

This is where privacy notices become important.

A privacy notice is simply an organisation being open with people. It is the organisation saying this is who we are, this is why we are collecting your data, this is what we will do with it and this is how you can reach us if you have concerns.

A proper privacy notice should help a person understand who is collecting their data and how to contact them. It should explain why the information is needed and what legal basis supports the processing. It should also explain whether the data will be shared, whether it will leave the country, how long it will be kept, and whether technology is being used to make decisions that may affect the individual.

The challenge, however, is that this is a lot of information. And this is where many organisations get it wrong.

Many organisations try to solve this by putting everything into one long document filled with legal terminology and technical explanations. From a compliance perspective, they believe they have done the right thing. From the user's perspective, however, nothing has really been communicated.

The truth is, most people do not want to read long privacy notices. Not because they do not care about their privacy, but because the information is often presented in a way that feels difficult to understand or disconnected from the moment they are providing their data.

Transparency should not feel like reading a contract. It should feel like being informed.

A more practical approach is to provide privacy information gradually and contextually. Instead of relying only on one long document, organisations can provide small explanations at the exact moment data is being collected.

For example, if someone is filling a form, a simple explanation beside the phone number field explaining why the number is needed can be more effective than hiding that explanation inside a long document. If a customer contacts support, a short notice explaining that conversations may be recorded for service improvement can achieve more transparency than a general statement buried on a website.

Privacy communication works best when it happens at the point where it matters.

This also applies to timing. When data is collected directly from individuals, the information should be provided at that point of collection. When the data comes from another organisation, there is still a responsibility to inform the individual within the timeframe required by law. Whether an organisation acts as a data controller or a processor, the responsibility to ensure transparency still exists, even though the obligations may apply differently.

It is also important to understand what privacy notices are not. They are not internal data protection policies. They are not legal essays. They are not technical compliance documents written only for regulators. They are also not documents that should be written once and forgotten.

Privacy notices are communication tools. They should evolve as business processes evolve. Most importantly, they should be written for people, not just for compliance files.

Because at the end of the day, privacy is not just about law. It is about respect. If a person feels surprised if they truly understand how their data is being used, then there is probably a transparency gap that needs to be addressed.

Privacy notices, when done properly, prevent those surprises.

If your organisation needs to review or improve its privacy notices or transparency framework, I am always open to how to make privacy communication clearer, more practical, and more effective.