Build a customer-data register from one business process
Share
Published
A customer-data register should describe how information moves through a business. It should not contain a copied list of customers. Start with one process, give each step an owner and record the details needed to understand the handover.
This worked example follows a fictional retailer delivering an order. It is designed to support the privacy operations guide for growing Nigerian businesses. Replace the example with your own process and obtain the legal review needed for your circumstances.
Start with the event that creates the record
Write the purpose in ordinary language: “Arrange and confirm delivery of an order.” Avoid a heading such as “customer management” that could include almost anything. Then ask where the information first enters the business: a website form, a call, a shop counter or a message.
For each route, inspect the fields actually collected. A field may be optional on the website but compulsory in a staff spreadsheet. The difference deserves a recorded explanation.
| Step | Information described | Recipient or access | Question to resolve |
|---|---|---|---|
| Order intake | Name, contact route, order reference and delivery destination | Sales role in the order system | Which fields are required for this order? |
| Dispatch preparation | Order reference and delivery instructions | Dispatch team | Can financial details be excluded? |
| Courier handover | The agreed delivery details | Approved courier contact or portal | How is the recipient verified? |
| Delivery confirmation | Status and the evidence needed for confirmation | Customer support and relevant operations staff | Does the evidence reveal unnecessary information? |
| Review and disposal | Remaining operational copies | Records owner | What rule and exceptions govern retention? |
Add the fields that make the register usable
For each row, record the system or physical location, process owner, purpose, categories of people, categories of information, internal roles, external recipients, approved transfer method and retention decision. Add the date checked and the source of the answer.
Leave an unresolved point visible. “Courier keeps copies; period not confirmed” is more useful than entering an invented period. Assign someone to ask the supplier, record its response and review whether the arrangement matches the business’s obligations.
NIST’s Privacy Framework resource repository includes inventory and mapping as a privacy-management area. The table here is an original, simplified way to start that work; it is not an official NIST form.
Walk through one record with the team
Use a test order and ask each person to describe what they receive and create. Look for downloaded files, printed labels, photographs of dispatch sheets and personal-device copies. A process diagram that shows only the main application will miss these working copies.
Do not paste real names, addresses or identity numbers into a presentation to prove the register is complete. The review can record a field name, a masked example and the location of the controlled original.
Keep purpose and retention decisions separate
An operational copy used to complete a delivery may serve a different purpose from an accounting record. The fact that one record must be retained does not automatically establish that every duplicate, chat attachment and label photograph needs the same retention period.
Ask the appropriate owner to document the applicable rule and any exception. Where a dispute or other obligation affects disposal, record the reason and who will review it. Avoid assigning one universal period to every row.
Turn the review into changes
Choose one improvement that can be verified: remove an unnecessary export column, restrict a shared folder or replace a publicly visible dispatch sheet. Name the person responsible and specify the evidence of completion.
A later customer request should be easier to route because the register identifies the owner and locations. The privacy-request handover checklist shows how the two records connect without exposing the underlying customer data to everyone handling the request.
When should the register change?
Review the relevant row when a collection form, supplier, recipient, purpose or storage location changes. Also revisit it when an incident reveals a copy or access route the team did not know existed. Record the change date so a future reviewer can distinguish current practice from an old assumption.
Featured image: AI-generated conceptual illustration.
