How to remove sensitive customer data from a software demo

To remove sensitive customer data from a software demo, follow four steps. Replace real values with made-up ones, starting with a global search and replace and then editing what's left by hand. Delete or blur anything you can't replace. Then have someone who didn't build the demo check every step before it goes out. The tools are the easy part. The hard part is deciding who owns the job. I think it belongs to the person who captured the screens.

Most leaked demo data isn't a breach. It's a customer's company name in a dropdown on step nine, a real revenue figure on a dashboard tile, or a colleague's email in the account menu. Nobody chose to share it. It came along with the capture. And the security review that came later checked the vendor's controls, not what was on the screens.

Why is masking a presales job and not a security task?

The obvious answer is that sensitive data is a security problem, so security should own it. That doesn't match how demos get made. Security teams review policies, certifications and access controls. They don't open every step of every demo. Even if they did, they couldn't tell a real customer name from a sample one.

Only the person who captured a screen knows what's real on it. The sales engineer knows that "Northwind" is made up and that the account in the second tab is a live customer from last quarter's proof of concept. A reviewer can't know that. So my position is simple. Masking is a presales job, not a security afterthought. The builder does the masking pass. A second person checks it. Security sets the rules for what counts as sensitive.

If your question is about the vendor side (SOC 2, SSO, link controls, what a security reviewer asks), read our security review checklist for enterprise demo software. This piece is only about getting the data off the screens.

Why do buyers notice what's in your demo?

Buyers already ask where their data will live, and websites only half answer them. The Storylane Buyability Index scanned 529 B2B websites between Sep 8 and Oct 20, 2026. Of its 10,580 buyer questions, 363 asked where data is stored or hosted. Only 44% got a full answer on the site, and 52% got a partial one. Two caveats apply. The questions are generated per company to reflect what a buyer would plausibly ask, not logged from real buyers. And the sites were chosen by the people who ran the scans.

Now think about your demo. A buyer can't get a clear answer about data handling from your website. Then they see another customer's name in your product tour. They have answered the question for themselves. At our booth at industry events this October, EU buyers talked about how strict GDPR makes them. For them, a real name on a demo screen isn't a small slip. It's evidence.

What counts as sensitive data in a demo?

More than names. Here's where real data tends to hide in a captured product.

The last row is the one people miss. Builders check the part of the screen they're talking about and skip the corners.

How to remove sensitive data from a demo, step by step

1. Start from a clean account if you can. The cheapest mask is data that was never real. A demo workspace with one made-up company beats any amount of editing. If your setup makes that hard, this guide to demo environment types walks through the options.
2. Write the swap list before you edit. Put the real value on the left and the made-up value on the right. Cover the company, people, domains and figures. One list keeps the story consistent, so "Acme" on step two doesn't become "Globex" on step six.
3. Run global search and replace first. It catches every match on every screen at once, including ones you'd never scroll to. Check the match count for each screen before you confirm.
4. Edit what's left by hand. Look for partial names, initials and numbers the search didn't catch.
5. Delete or blur what you can't replace. This covers images, avatars, logos and charts. Prefer deleting or replacing over covering. A replaced value is gone. A covered one is only safe while the cover stays in place.
6. Check the places masking misses. Look at hover states, closed menus, tooltips, the browser tab title, chart labels and any step you added after the first pass.
7. Run the stranger test. Someone who didn't build the demo clicks through every step and flags anything that looks real. They don't know what's fake, so they catch what the builder stopped seeing.
8. Repeat on every copy. A demo copied for a new buyer keeps its masking. But anything you recapture for that buyer starts unmasked.

Should you blur, hide or replace?

Replace when you can. Delete when the element adds nothing. Blur when the layout of the screen matters but the content doesn't. Hiding is the weakest option for truly sensitive data, because a hidden element is meant to come back. It's a layout tool, not a masking tool.

Replacing also makes a better demo. A blurred table tells the buyer something is being kept from them. A table full of believable sample data shows them what their own account will look like.

How this works in Storylane

I'm biased here, since this is our product. In the Storylane editor, each step above has a built-in tool. On HTML screens you can edit any text directly. You can run a global search and replace that lists the matches on each screen before you confirm. You can also blur, hide or delete single elements. On screenshot screens you draw a blur area, set how strong it is, and apply it to all steps.

Storylane also has personalization tokens. You can insert text and image tokens so a prospect's name or logo fills in when you share the demo, instead of being typed into the capture. That makes it a good fit for presales teams who send many versions of the same demo and want each one clean.

Whatever tool you use, the swap list and the stranger test are your team's job. They are what make the tools work. And if a buyer needs to see their own data inside the product, that is a proof of concept, usually with a data processing agreement, rather than a demo.

What to do on Monday

Pick the three demos your team sends most often and run the stranger test on them. Then make the masking pass part of building every demo. Make the person who captures the screens the owner, and save the swap list next to the demo. If you sell to security teams, the stakes are higher. Showing detections without live threat data takes the same discipline with less room for error. It pairs well with answering the security questionnaire without stalling the deal.

If you'd like to see the masking tools on one of your own demos, book a walkthrough with our team.