How to mitigate data breach damage


In just the first quarter of 2016, there were 139 reported data breaches – resulting in almost 4.3 million exposed user records, according to the Identity Theft Resource Center (ITRC).

For all businesses where internal data was exposed, this can mean compliance breaches and employee identity fraud can result.

For businesses where customer data was exposed, this can additionally result in broken customer trust, loss of existing or new business, or lawsuits that can result in hefty fines.

Ideally, all data breaches would be prevented. However, this is not always the reality. In this article, we discuss how scoped access can help mitigate the damage.

For context, the user record count includes any incident in which the individual name – plus a critical identifier like a Social Security number, driver’s license number, medical record or financial record – is exposed. But it doesn’t include records that expose usernames, emails and passwords without involving sensitive personal identifying information. This would drive the total record number even higher (ITRC lists these breach incidents but without the total number of records exposed).

>See also: 4 guiding principles of mobile login

While some of this information was exposed by hackers accessing databases or physical theft of unencrypted data or devices, others were exposed through subcontractors or employee error, specifically involving phishing attacks or allowing their access information to fall into the wrong hands.

The Identity Theft Resource Center report lists a number of examples, including a phishing attack on a hospital resulted in four staff email accounts being compromised. Such email accounts could be used to reset passwords in related systems to access protected data.

In another case, a company was the victim of an email spoofing attack, in which the employee provided information to whom they believed to be the CEO, when in fact, it was a malicious third party.

At a large data storage company, an employee was tricked into providing Social Security numbers and other personal data through a phishing attack as well.

These types of breaches are damaging when they occur with partner or employee data, but they can be devastating when they occur with customer data.

In 2013, Target’s data breach of 40 million credit and debit card numbers, plus 70 million customer records (including addresses and phone numbers), resulted in a fine of  $252 million.

For a company like Target, this isn’t a crippling sum, but the financial penalty could be a major burden for a smaller organisation. And even if financial information isn’t exposed, the customer relationship will be damaged when customers no longer trust the organisation to be a good steward of their data.

So how does scoped access help? The more people who need or use data, the more exposure there is to the possibility for unintentional data leaks. Scoped access helps by ensuring that only the minimum level of data is available to each individual.

Support, marketing, technical and administrative employees in an organisation access customer data for different reasons. As a support person, an employee may need to access customer login information to assist a user who is trying to log in, or provide information to them about their account data.

To this end, the support person should be able to see the information they need to support the customer. The support person should not, however, have access to the password information for the user, but instead is able to trigger a password reset flow that requires the user to validate their identity.

This approach protects the support person from the phishing techniques discussed above, where data was provided to a malicious party masquerading as someone entitled to the data.

For all other data, it’s always preferable for the support person to facilitate the user’s ability to self-authenticate and manage data, rather than providing direct access to the data itself.

In another example, a technical employee may need access to end-user data in order to validate implementations or to confirm that products are functioning as expected.

The technical employee may need access to an administrative level of data, in order to program the interfaces that move user data from place to place.

In as many cases as possible, the technical employee should use test or dummy data to do all development and testing of any implementation or integration.

Once the testing is complete and the system is turned on, any authorisation granted should be abstracted out to a key and secret or administrative user if possible and stored in a secure vault which is accessed in a programmatically secure way.

Those technical users with access to such privileged data should be minimised in an organisation with strict rules in place about how and when that information can be shared.

Quite the opposite of the technical employee, a marketer may need the user data in order to guide decisions on where to invest advertising and develop programmes on how to improve customer relationships or market to groups similar to their current user base.

In this case, individual user information should be limited or avoided if possible. Instead, users should be segmented and analyzed statistically to provide marketing with the aggregate view of the users that they need to generate value out of the user data.

Scoped access is already a tenant of good access management practices for an internally focused IT organisation. Information Technology Infrastructure Library (ITIL) emphasises access management as part of the service operations portion of the framework, highlighting the need for information security management that enables the organisation to “manage the confidentiality, availability and integrity of the organisation’s data and intellectual property”, as highlighted in the Universities and Colleges Information Systems Association’s (USICA) ITIL guide.

Scoped access is part of the process that allows an organisation to maintain the confidentiality of its information by ensuring employees have the right level of access to do their jobs, but not more.

When used in conjunction with audit logs and the ability to easily grant and revoke access, scoped access is a critical part of a comprehensive access management strategy, so much so that it’s often a required part of security and control certifications.

The idea of scoped access isn’t new, but the stakes and roles change when the data introduced is customer rather than internally focused.

As discussed in the earlier description of the roles of users who access customer data, there is a wider range of employees who may need access to customer vs. internal data.

A marketing organisation needs to understand the customer base to improve targeting and relationship building efforts, technical teams need to develop integrations and tools that utilise customer data, and support staff needs to assist customers with their accounts.

An organisation won’t just need to limit access to the data, but will need to limit access to specific types of data as well. This makes the ability to create a custom access level a critical feature need in the customer identity access management (CIAM) space.

There are a few ways in which scoped access can be accomplished in a CIAM solution. The most flexible is to allow the ability to generate scoped API access to the customer data. This means generating an API client with read and/or write access to specific fields.

Generating this level of access allows an organization to build user interfaces on top of the data that can grant access at a fine level of granularity. It can be used to create a GUI that allows different support personnel to have exactly the right access based on their seniority or area of expertise.

It also allows an organisation to build scripts and integrations that are permitted to see exactly the data they are allowed to consume. This is especially helpful when integrating with third party tools that don’t require Personally Identifiable Information (PII), such as business intelligence, segmenting or data science tools.

>See also: 5 layers of customer identity

It means there is far less risk in adding these types of integrations to a platform because there’s no risk of customer data exposure due to security lapses caused by the third party.

Another mechanism for scoping access is through interfaces that only allow specific data to be shown. CIAM tools that have interfaces built for a particular function can supercede the need for specialised APIs by providing the graphical user interface that an employee needs to get exactly the data they need, and none of the data they don’t.

Customer resource management tools are built for exactly this type of work, allowing employees to access customer records at precisely the right level.

Likewise, business intelligence tools can work similarly, allows employees who are entitled to see aggregated data see only that information, while allowing employees with more privileged access the ability to see the records behind the aggregate as well.

There is a wide variety of ways and means of establishing scoped access for customer specific data. The mechanism isn’t important, as long as an organisation thinks through all of the customer data it holds and establishes who, how and when that data can be accessed by all of the roles within the company.


This article is sourced from Marla Hay, director of product at JanrainJanrain is a customer identity management platform on the cloud. It helps companies build a unified view of their customers across all devices by collecting accurate customer profile data to power personalised marketing. 

Avatar photo

Ben Rossi

Ben was Vitesse Media's editorial director, leading content creation and editorial strategy across all Vitesse products, including its market-leading B2B and consumer magazines, websites, research and...

Related Topics

Data Breach