Data Masking

What are we trying to solve by masking, and what do we want to achieve and for whom?


  • Organizations copy production data into non-production test and development environments to test upgrades, patches and fixes.
  • Businesses require new and improved functionality in existing production applications. As a result application developers require an environment mimicking close to that of production to build and test the new functionality ensuring that the existing functionality does not break.
  • For whom, which audiences?

  • Internal, those users within the secure environment of the organization, including sub contracted service providers.
  • External, those users outside the secure environment, for example a vendor support team.
  • What do we want to achieve?

  • Create an operational framework that supports the distribution of non-prod data in a timely manner, that limits the exposure of sensitive data based of the activity of the user or group
  • Replace sensitive data with fictitious yet realistic data, neutralise data risk while preserving the value of the data for non-production use.
  • Select conservative Algorithm choices; too much complexity creates management
  • What we want to avoid?

  • Specific algorithm choices that require applications to go through a major change.
  • FWD View proposes a Framework

    All organisations have a requirement to obfuscate (mask) data to meet security and regulatory requirements, across the total enterprise, in both production and non-production. Data protection needs to be part of the system design and testing process

    Masking will change the process of creating data for Non Production. To manage that change an operational framework needs to be inserted in to the existing support process. It needs to describe

  • The process of handling a new data store or configuration change
  • The process of identifying an Algorithm for a sensitive element
  • Identifying Data Validation related Requirements
  • Evaluating Performance Needs, based on the current observation
  • Capturing Integration touch points, for executing Data Masking as batch jobs or offline processes, along with an existing Refresh process
  • To achieve a coordinated, enterprise-wide masking solution a data map needs to be created so the flows and dependencies can be traced / documented and the risk of data exposure can be assessed

    Trade Offs

    Data masking incurs trade-offs, between hiding data and achieving a functioning application, dependent upon the application and its implementation. The ability to help debug a production scenario in non production environment needs to be evaluated against the risk to exposure. A proxy solution in place gives the ability to take in a real value from the application, and replace it with the pseudo value is something that needs to be explored.

    As an example

  • counterparty “BankA” could consistently de-identify to “ITCD”; this might been sufficient to use this pseudo ID to troubleshoot a single issue in non production.
  • The trade off is where the pseudo ID does not meet then need for all business units where counterparty is used in the application, and causes the failure in process or result. It is for this that trade-off between risk of exposure and the risk of the application failure. Hence the need for differing solutions for each business unit


    The objective of masking is to reduce the risk of exposure of sensitive data. Masking of data is often a trade off between what can technically achieved and what is practical

    We could mask every element of data within the application, database, lookup table, temp tables etc., but the application would be difficult to support / develop / test. There is not a complete one-stop masking process due to the constraints of the implementation and custom code.

    Our proposal is for a multi-tiered approach to data masking, this allows the selection of the appropriate level of masking for the users and task.

  • Dynamic Data Masking – only mask what you want to create a unique set of unmasked data
  • This approach makes it easier process to mask data for

  • external use, data that is exposed to organizations outside of the secure boundaries, e.g.. data sent to a vendor for maintenance
  • Internal use, data used within the secure boundaries for internal support teams, development and testing
  • FWD-View offer consultancy to set up Delphix masking with lots of experience in Financial Services. Combined with Waterline this would give us a ‘proper’ platform for GDPR compliance

    Head of BI Solutions - Asset Management