Use this transfer decision worksheet
Start with one personal-data field, such as an ID image. Follow it through collection, storage, support, analytics, crash logs, backups, and deletion. Mark both server location and people who can view it remotely.
| Item | Check or owner | Evidence |
|---|---|---|
| Source | Where is data collected? | Country, product, and purpose |
| Destination | Where is it stored or viewed? | Region and recipient |
| Path | How does it move? | API, support, backup, or analytics |
| Review | Who checks transfer basis? | Record decision and date |
Apply the evidence map
List each recipient and purpose. The same vendor can have a second transfer through support access even when its database is local. Use the map to assess the Act’s transfer rules; keep the legal decision and safeguards as a separate signed record.
Decide what to do with an unlisted path
A newly found destination is an open review item, not a completed transfer assessment. First stop sending fields that the receiving tool does not need. For an error service, replace full account IDs with an opaque event ID and rerun the seeded-record search. Record the old and new payload schema, vendor configuration, and date of the fix. If a support team abroad must view a customer record, restrict the fields and access duration, then give the privacy reviewer the exact recipient, purpose, and safeguards. The technical owner should confirm the changed traffic; the privacy reviewer should make the separate legal decision. Keep both approvals with the map.
Evidence to keep
Validate the map with a seeded identifier. Search for it in the primary database, logs, error tool, support console, analytics, and backup index. Note which copy can be viewed abroad and which copy is physically stored abroad. The privacy reviewer can then apply the Act to real paths. If an unwanted copy appears in error logs, remove the field at collection and keep a safe event ID for debugging. A map should be updated from observed traffic, not only vendor sales material.
Trace one support ticket across borders
Synthetic case: a Nigerian customer opens a support ticket. The ticket is stored in Lagos, copied to an overseas helpdesk, indexed by an AI search service, and included in a backup. Draw each hop with data fields, country, recipient, purpose, retention, and access route. Include overseas staff viewing and download access as paths for the privacy review even if the primary database stays in Nigeria.
Now remove the customer’s attachment and check whether the helpdesk copy, AI index, and export queue also change. Record any copy that remains and why. Sections 41–43 of the NDP Act address transfers of personal data outside Nigeria. A flow map is the input to that legal review, not the legal basis itself. Have the privacy owner record the transfer mechanism and recipient safeguards for each destination.
Record the transfer basis beside each path
Section 41 of the NDP Act requires a basis for sending personal data outside Nigeria and a record of that basis and protection assessment. Section 42 covers adequacy; Section 43 supplies other grounds subject to their conditions. GAID Article 45 points to Schedule 5 for transfer evaluation pending further instruments. A cloud-region label alone does not select one of these grounds.
For each overseas storage or remote-access path, record recipient, destination, purpose, fields, onward recipients, protection mechanism, and privacy decision. Remote viewing belongs in the map for assessment even when the database stays local. Include whether staff can download, whether sessions are recorded, and how access ends. Protect the legal assessment separately from the technical traffic trace.
In the fake support-ticket test, compare the helpdesk payload with its search and backup copies. Removing an attachment from the app does not prove the overseas copy vanished. Assign an owner to each residual copy and its deletion or lawful retention rule. Recheck the transfer basis when destination, vendor purpose, data category, or onward sharing changes.