Who in your company should see which customer data?

Connecting your customer data makes it more useful, and more exposed.

Sales trusts HubSpot. Finance trusts Stripe. Support trusts Zendesk. Join them into one view, as in our renewal-risk use case, and you've created the most complete picture of each customer in the company. That's the point. It's also a new risk: before, someone needed three logins to see everything; now one view shows it all.

This use case is a simple way to start governing that data in a company of 20–50 people. Five steps, each with a table you can copy.

Practical guidance, not legal advice.

Why this matters now

Most small teams never decide who sees what. Access grows by default: a new hire gets "the same as Sanne", a CSV export lands in a shared drive, someone pastes a customer list into a chatbot to get a quick summary.

That last one isn't hypothetical. The Dutch Data Protection Authority has received data breach notifications from organisations whose employees entered personal data into AI chatbots, including a telecom employee who uploaded a file of customer addresses. Its advice is to make clear which data employees may and may not enter (Autoriteit Persoonsgegevens).

The goal isn't to give everyone access to more data. It's to give each person, and each system, access to the data they actually need.

1. Map where customer data lives

Start with one table: every place customer data is stored, including the unofficial ones.

The last two rows are where the surprises are. Ask the team; don't guess.

This map also helps with your GDPR obligations. GDPR expects organisations to know what personal data they process, why, who has access and how long they keep it (Article 30). This table is a practical starting point.

2. Name an owner for every source

Every source needs one person who decides how it's used. Not a committee: a name.

Governance isn't only about who can see data. It's also about whether the data they see can be trusted. Owners and stewards are who makes sure "active customer" means the same thing everywhere, and that Northwind in the CRM is the same Northwind in billing.

3. Decide who sees what

Give each person, and each system acting for them, only the access needed for their job. NIST calls this least privilege (SP 800-53, AC-6). Think in data categories rather than tools:

This is an example, not a rule. What matters is that someone filled it in on purpose. Two things to notice:

• "Status only" is a real option. A CSM needs to know an invoice is 23 days overdue. They don't need the customer's bank details.
• Treat AI as another actor in your access model. An AI agent isn't an exception to your permissions; it's another identity in them, with its own, usually narrower, access. And as agents start doing things, not just reading, the same question extends to actions: may it update the CRM, send an email, export a list?

Most tools support this already: permission sets in HubSpot, restricted roles in billing, agent roles in support. The connected view is where it's most often forgotten, because it starts as "just a report".

4. Control how data leaves, and keep a trail

Data rarely leaks from the system. It leaks from copies.

• Exports. Decide who may export customer lists and where exports are stored. One shared folder with an owner and a clean-up date beats twelve "Downloads" folders.
• Vendors. Every tool that processes your customers' personal data on your behalf needs a data processing agreement (GDPR Article 28). Keep a list of them and what they receive. Your own customers will ask for it.
• AI tools. Write the rules down. A starting point:
  1. Only approved AI tools, on business accounts with training on your data switched off.
  2. No customer contact details, payment details or full support conversations in unapproved tools.
  3. AI drafts; a person sends.
  4. A new AI tool goes on the vendor list before it gets customer data.

Access rules say what should happen. An audit trail shows what did: who exported what, which system queried which customer, who granted access, which identity match was changed. Most tools keep some of this already; switch it on and know where to find it.

5. Set retention

Personal data shouldn't be kept longer than its purpose needs (GDPR Article 5). Decide per category:

The middle periods are examples; choose and document your own. What matters is that deletion actually happens.

-- A deliberately limited view: account context, no contact details, no ticket text
CREATE VIEW customer_context AS
SELECT customer_id, customer_name, renewal_date, open_invoice_eur, open_tickets
FROM customer_360;

-- The AI assistant gets its own identity, with access to that view only
CREATE ROLE ai_assistant NOLOGIN;
GRANT USAGE ON SCHEMA public TO ai_assistant;
GRANT SELECT ON customer_context TO ai_assistant;

What usually goes wrong

• Access only grows. People change roles and keep old permissions. Review access every quarter; remove it the day someone leaves.
• The connected view becomes the most sensitive dataset. It deserves the strictest access, not the loosest.
• Exports and AI tools create uncontrolled copies. Last year's churn export, with every contact email, is still in a shared folder.

And one misconception: "EU-hosted" isn't the same as "compliant". Where the data sits is one question. Who accesses it, why, for how long, and whether it can be deleted are the others.

Before you connect anything

Your data doesn't need to be perfectly governed before you start connecting it. But you should know what you're exposing before you do.

In a Seamline diagnostic, we map the systems involved, how customer identities connect, who can access the resulting data, and what controls are needed before putting AI or automation on top.

Book a revenue data diagnostic →