What an NDPR compliance audit
looks at, in order

If your organisation processes personal data in Nigeria and falls above the threshold the Nigeria Data Protection Commission sets, you file an audit return every year. The return is not a form you fill in one afternoon. It is a description of your data processing, signed off after someone has actually checked it.

We have been on both sides of that desk: building the systems that produce the evidence, and helping clients assemble it before a filing deadline. The pattern of what fails is consistent.

What changed when the NDPR became an Act

The Nigeria Data Protection Regulation came out of NITDA in 2019. It worked, in practice, like a regulation with real enforcement teeth: audits, filings, and penalties calculated against revenue. The Nigeria Data Protection Act 2023 replaced it with statute and created the Commission as the regulator.

The Act moves obligations that sat in a framework document into law, gives the regulator power to investigate without waiting for an audit, and requires organisations of major importance to register and appoint a Data Protection Officer. The annual audit cycle carried over. If you have an NDPR audit report from last year, it is still the right shape of document; it now needs to reference the Act.

Who files

Two questions decide it. Do you process personal data as a controller or processor, and does your volume or sensitivity put you in the category of major importance? Banks, telcos, hospitals, insurers, and most fintechs are clearly in. Schools, SMEs, and SaaS companies are sometimes surprised to find they are too, because the test looks at the number of data subjects and the nature of the data, not at headcount or turnover alone.

If you are unsure, ask the Commission directly rather than assuming. Filing when you did not need to costs you an audit. Not filing when you did is the expensive mistake.

The audit starts with an inventory, not with a questionnaire

An auditor cannot evaluate controls over data they cannot locate. The first working session is almost always a data inventory: what personal data you hold, in which system, for what purpose, who inside the company can see it, and which third parties receive it. In GDPR language this is the record of processing activities. In practice it is a spreadsheet that took two weeks to build and is out of date the moment a new integration ships.

Most Nigerian organisations have this data spread across an ERP, a marketing tool, a payroll system, a WhatsApp business number, and at least one spreadsheet on someone's laptop. The audit client that sails through is the one whose inventory was maintained continuously rather than reconstructed under deadline.

Lawful basis and consent records

For each processing activity, you name the lawful basis. Consent is the one everyone reaches for, and it is usually the weakest-evidenced. If your signup flow shows a checkbox, the auditor will ask for the version of the consent text that was live on a given date, the log showing which users accepted it, and what happens when someone withdraws.

Many Nigerian sites cannot answer the third question at all. Withdrawal should be as easy as giving consent, and it should propagate to every system that received the data, including your email platform and any analytics tool.

Third parties are where audits get uncomfortable

You remain responsible for data your vendors hold. The auditor will ask for a list of processors, a contract with each one that includes data protection terms, evidence that you assessed them, and the countries where the data is stored or processed. That last question catches a lot of companies: a US-based CRM, a cloud region in Europe, and a support team in another country all create transfer questions that need a documented answer.

If your vendor list is only known to the operations manager and not written down, treat that as the first gap to close.

Security controls, evidenced rather than described

This section is where a policy document is not enough. Expect requests for:

Access control records showing who has production access and when it was last reviewed.

Evidence that leavers lose access on the day they leave.

Encryption at rest and in transit, with the specific configuration.

Backups, and a record of a restore that actually worked.

Logging and monitoring, with retention periods.

Vulnerability scanning or penetration testing results for internet-facing systems.

A policy that says "access is role-based" without an export from the identity system behind it will be marked as unsupported.

Breach response

The Act requires notification to the Commission within a defined window after you become aware of a breach, and notification to affected data subjects where there is risk. Auditors look for a written procedure, a named owner, a contact route that works outside office hours, and a log of incidents including near misses.

A company that has never logged a single incident is not automatically clean. It usually means nothing was being watched.

Cross-border transfers and retention

Two questions that quietly matter. Where does the data go, and how long do you keep it? Retention is the one most often answered with "as long as needed", which is not an answer. Each category of data needs a defined period and an automated way to delete or anonymise at the end of it. If deletion is manual, the auditor will ask who does it and when they last did.

What gets flagged most often

From what we see, the recurring findings are unglamorous. An out-of-date inventory. Consent records that cannot be tied to a specific version of a policy. Vendors with no data processing agreement. An email marketing tool nobody remembered to list. A retention period that exists in policy but not in code.

None of these require a new platform. They require someone to sit with the systems and write down what is true.

What to prepare, in order

Work in this sequence and the audit takes weeks instead of quarters.

1. Build the inventory and keep it as a living document with an owner.

2. Map every third party that touches personal data and check each contract.

3. Pull access lists, backup restore evidence, and vulnerability reports from the systems themselves.

4. Write the retention schedule per data category, then implement deletion where it is missing.

5. Document the breach process and test the contact route.

6. Only then draft the report, because the report describes the six steps above.

After the filing

The audit return is a snapshot. The remediation items it produces are the actual work, and the Commission expects progress before the next cycle. Companies that treat the filing as an annual emergency repeat the same remediation list every year.

The cheaper path is to make the evidence a byproduct of normal operations: an inventory updated when integrations ship, access reviews on a calendar, vendor contracts checked at procurement. Then the audit is a readout rather than a project.

If you need the current filing requirements for your category, the Commission publishes them directly and they change. We are happy to walk through what we look for when we build or assess a system, and to say plainly where your evidence would not hold up.