Post

Securing Email Communication: Preventing Accidental Customer Data Leaks

Discover how we implemented strategies to avoid accidental information leaks in customer communications by training our team and developing an Outlook macro to block inappropriate emails.

One of the teams I manage provides technical advisory to end users of customer product. My team communicates with customers through a customer provided CRM system. When they need to discuss matters internally (across multiple domain email IDs) with technical experts or conduct reviews, they rely on Outlook-based mail communication.

Any communication done through the CRM system automatically populates in Outlook. However, any communication done using Outlook mail by “reply to all” is also sent to customers.

It’s crucial to avoid sending one customer’s information to another. If this happens, it’s considered an information security incident, and we must apologize to both customers and undertake many internal activities, which is the last thing we want to happen.

Unfortunately, emails meant for internal review were frequently being sent to the same customer or another customer by accidentally pressing “reply to all.” This was occurring often and quickly eroding customer confidence.

To address the problem, we implemented two strategies:

  1. Ensure team members understand the consequences of inadvertently pressing “reply to all.” This involved changing their mindset and taking utmost care in handling internal review emails.
  2. Develop an Outlook VB Script that blocks such email sendings.

Outllok Macro Idea

Here’s how we developed the Outlook macro in more detail:

  1. Prepare an Excel sheet with internal stakeholders’ email IDs and copy it to a common SharePoint folder. We call this the “allowed list.”
  2. Whenever a team member presses the send button in Outlook, a callback function “MailItem.Send” is triggered.
  3. Validate that all the email IDs in the “To,” “CC,” and “BCC” fields are listed in the allowed list.
  4. If the email IDs are in the allowed list, the team member can send the email; otherwise, an appropriate error message is shown, and the email sending is canceled.

Note:

  • Whenever new members are added or removed from the review team, updates must be made to the “allowed list.”
  • To address performance issues, we moved the reading of the SharePoint allowed list file to occur during Outlook launch instead of during the email sending callback.

By implementing these strategies, we have significantly reduced the occurrence of information security incidents, thereby maintaining customer confidence and protecting sensitive information.

This post is licensed under CC BY 4.0 by the author.