NDPA Data Mapping for Nigerian SaaS Startups

Why a Data Map Should Come Before Another Policy

Many Nigerian SaaS teams can name their cloud provider, payment gateway, and email platform but cannot trace one customer's personal data through the complete product. A signup may place a name and email address in the application database, analytics platform, support inbox, billing system, backups, and exported spreadsheets. Each copy creates a different access, retention, transfer, and deletion question.

The Nigeria Data Protection Act 2023 (NDPA) makes accountability an operating requirement. The Nigeria Data Protection Commission's General Application and Implementation Directive 2025 (GAID) adds practical guidance for controllers and processors. A privacy notice alone cannot show how your systems actually handle personal data. A maintained data map can.

This guide gives founders, engineering leads, and operations teams a practical starting point. It is general operational guidance, not legal advice. Confirm legal interpretations, registration status, and filing duties with a qualified Nigerian data protection professional.

What an NDPA Data Map Contains

A data map is an inventory of personal data and the paths it follows. It should answer seven questions for each processing activity:

1. What personal data do we collect or create?
2. Whose data is it?
3. Why do we process it, and what lawful basis supports that purpose?
4. Where is it stored or accessed?
5. Who receives it, including vendors and affiliates?
6. How long do we keep it?
7. Which security and deletion controls apply?

The result can begin as a controlled spreadsheet. The tool matters less than clear ownership, consistent fields, and evidence that the entries match the product.

Do not limit the map to the production database. Include website forms, product analytics, customer support tools, source-code issue trackers, logs, backups, finance records, applicant records, and employee systems. SaaS data often spreads through integrations faster than teams expect.

Step 1: Define Roles and Scope

Start by identifying when your startup acts as a data controller and when it acts as a processor. For example, your company may decide why and how it uses employee and direct marketing data, making it a controller for those activities. It may process records inside a business customer's workspace only on that customer's instructions, which can place it in a processor role.

The distinction affects contracts, notices, request handling, and incident coordination. It can also change within the same product, so avoid assigning one role to the entire company without examining each activity.

Set the map's scope across:

• The marketing website and lead forms
• Account registration, authentication, and profiles
• Core product records and user-generated content
• Payments, invoices, and fraud controls
• Support tickets, calls, and chat history
• Product analytics, monitoring, and audit logs
• Staff, contractor, and recruitment records
• Backups, exports, test environments, and deleted accounts

If you need technical support finding untracked exposure across these systems, a cybersecurity assessment can connect the inventory to access, logging, encryption, and incident controls.

Step 2: Follow Real Data Through the Product

Use a recent signup, support request, billing event, and account deletion as walkthroughs. Ask the people who operate each step to show what happens rather than describing the intended architecture.

For a signup flow, record the fields entered, server logs created, database tables updated, emails sent, analytics events fired, and vendors called. Note whether an engineer can view the record in an admin panel and whether support staff can export it. Repeat this for sensitive or high-risk flows.

Pay particular attention to data that is easy to overlook:

• IP addresses, device identifiers, and session records
• Free-text support fields that may contain identity or financial details
• Uploaded identity documents or profile images
• Location, health, biometric, or children's data
• Failed payment logs and gateway references
• Internal notes about customers
• Production data copied into development or debugging tools

A system diagram helps engineers, but the working register also needs business context. “PostgreSQL customer table” is not enough. State the data subjects, purpose, recipients, retention rule, and owner.

Step 3: Record Purpose and Lawful Basis

Every row should connect a specific purpose to an appropriate lawful basis under the NDPA. Do not write “business operations” for everything. Useful purposes are narrower, such as authenticating a user, delivering a subscribed service, preventing account abuse, issuing an invoice, or sending requested product updates.

Consent is not the automatic answer. Depending on the activity and legal review, another recognised basis may be more appropriate. When consent is used, record how it is collected, how the person can withdraw it, and which systems must respond to that withdrawal. Avoid bundling optional marketing permission into acceptance of service terms.

Also compare the map with customer-facing notices. If the map shows an analytics or support vendor that the privacy notice does not describe, update the notice. If a notice promises deletion after a fixed period but backups retain records longer, resolve the mismatch rather than hiding it.

Step 4: Build the Vendor and Transfer Register

Most SaaS startups rely on subprocessors. For each vendor, capture:

• Service name, purpose, and internal owner
• Categories of personal data and data subjects
• Hosting and support-access locations
• Contract and data processing agreement status
• Approved subprocessor list and change process
• Security evidence and breach notification terms
• Export, return, and deletion options at contract exit
• Cross-border transfer assessment and safeguards

Do not assume a familiar global brand removes your responsibility to understand transfers. The NDPA addresses transfers of personal data outside Nigeria, and the required assessment depends on the destination and safeguards. Have counsel or a qualified privacy professional review the mechanism used for material transfers.

Vendor discovery should include code and operations. Review package integrations, environment configuration names, webhook destinations, tag managers, finance tools, and shared team accounts. A card on the company expense statement may reveal a processor missing from the architecture diagram.

Step 5: Add Retention and Deletion Rules

“Keep while useful” is not a retention policy. Give each activity a trigger and a period or review rule. Examples include account closure, contract expiry, resolution of a support case, or the end of a legally required finance-record period.

Then test whether the product can carry out the rule. Deleting a primary database row may leave copies in object storage, search indexes, analytics profiles, support tickets, and backups. Backups may require a documented expiry cycle rather than selective deletion, but restored data must not silently return to normal use.

Map deletion responsibilities across the startup and its vendors. Record exceptions for legal claims, security investigations, or statutory records separately, with access restricted to the exception's purpose.

Step 6: Link the Map to Risk and Security

Add a simple risk view to each activity: sensitivity, volume, vulnerable data subjects, access breadth, automated decisions, transfer exposure, and consequences of misuse. High-risk processing may require a Data Privacy Impact Assessment before processing begins. The NDPC's guidance should be checked against the actual design, not after launch.

Connect each system to concrete controls:

• Role-based access and prompt offboarding
• Multi-factor authentication for administrative tools
• Encryption in transit and at rest where appropriate
• Audit logs for sensitive reads, exports, and changes
• Secret management and production access approval
• Tested backups and incident response procedures
• Masked or synthetic data in development environments

Products shown on our product portfolio illustrate why operational workflows and data protection must be designed together. Health, retail, and event platforms handle different data and need different access, retention, and recovery decisions.

A Minimum Viable Register

For each processing activity, use these columns:

| Field | What to record | |---|---| | Activity and owner | Clear workflow name and accountable team | | Data subjects | Customers, users, staff, applicants, or visitors | | Data categories | Contact, account, payment reference, usage, or sensitive data | | Purpose and lawful basis | Specific outcome and reviewed basis | | Systems and locations | Application, vendor, backup, region, and access location | | Recipients | Internal roles, customers, processors, and other parties | | Retention and deletion | Trigger, period, exception, and deletion method | | Security controls | Access, encryption, logging, backup, and testing | | Risk and action | Current risk, gap, owner, and target review |

Keep evidence beside the register: architecture diagrams, vendor agreements, privacy notices, consent records, retention procedures, and completed risk assessments.

Turn the Map Into a Repeatable Process

A one-time workshop becomes stale as soon as the product changes. Add privacy questions to engineering design reviews and vendor procurement. Require a map update when a team adds a field, integration, region, analytics event, or new use of existing data.

Review the register on a defined cadence and after material incidents. Product owns data use, engineering owns technical flow accuracy, security owns control evidence, and legal or privacy specialists validate obligations. One named coordinator should track unresolved actions.

Your first pass does not need to be perfect. Start with high-risk and high-volume flows, verify them directly, then expand. The useful output is not a polished spreadsheet. It is a shared view of where personal data goes and a prioritised list of gaps the team can close.

If your SaaS startup needs help mapping systems, assessing technical controls, and turning findings into an implementation backlog, contact Techzoid Innovation. We can support the technical work while your legal adviser confirms the binding compliance decisions.