Data Masking

Data masking permanently masks, or obscures, data in a non-production environment to protect sensitive or personally identifiable information (PII) from users who access that environment. By masking PII, you allow users to conduct user acceptance testing with production-like data in test and development environments, while remaining in compliance with regulatory requirements such as Sarbanes-Oxley, PCI DSS, and HIPAA.

You can run data masking on your non-production environments either in conjunction with an environment refresh or as a standalone job. The first option is the most common and assures that the production data you migrate to a test or development environment is masked before you provide users access to it. The second option is less common but is useful if you have loaded information from another system directly into your non-production environment or if you previously ran an environment refresh but did not apply masking at the time.

Data is masked based on a template provide by Oracle. The template defines the masking rules applied to the different types of PII data fields. For examples, see How Your Data is Masked.

Ensure that you are aware of the following impacts of data masking before you apply it to your non-production environments:

• Data masking requires up to 24 hours downtime. If you are running data masking with an environment refresh, this time is in addition to the time required for the refresh data migration.
• Data masking is irreversible. If you subsequently require unmasked data in the environment, you will need to run an environment refresh without data masking.
• If you have non-Fusion systems that integrate with HCM, give special consideration to:

  • The timing of the Fusion HCM data masking to coordinate with any non-Fusion system's planned content migration, cloning or other refresh activities in order to avoid potential data integrity issues.

  • Any impact of masked data to downstream processing and systems. For example, the data masking process truncates all national identifier data rows. Therefore, if the national identifier field is a mandatory field in a downstream test system, then validation will fail because the national identifier values don't exist.
• In many cases, the use of masked data results in different, noticeable results than the source data because the values are different. Any process that leverages this data may render different results. Notable examples include:
  • Email notifications sent from the masked non-production environment are all routed to the same discard domain, "sendmail-test-discard@oracle.com" and will not be delivered to individual email addresses.
  • Addresses: Masking will shuffle Postal Code, Town or City, and Country values. Therefore, masked persons on the database may have data that is inconsistent with their assigned home address. In addition, any process that leverages address components will give different results due to the shuffled values. Examples include processes to determine eligibility, or to perform benefits and payroll calculations.
  • Dates of Birth are randomly assigned within a range of January 1, 1945 and December 31, 1990, so person ages will be different after masking. This affects age-based reporting and processing.
  • Person Names: Components of a person's name are separately shuffled across the database, so the resulting full name can be inconsistent with the assigned person's gender.
  • Documents of Record, Disabilities, Driver's Licenses, Passports, Visa, and Work Permits likely will be unusable by any report or process that leverages them due to the masking techniques applied to these types of data.
  • National Identifiers are removed. Although payroll calculation processes do not require a National Identifier, payroll reports, pay slips, and outbound payroll extracts will not contain National Identifiers.

There are no required steps to enable data masking. You'll see the option to run data masking under the More actions menu in the environment details page of your test and development environments and also as an option when you refresh one of these environments.

You have the option to refresh and mask data together.

See Environment Refresh Management Tasks for details and requirements for submitting a refresh request. By default, data masking is disabled, but you can enable it when you submit the request.

The data masking process adds to the downtime of the refresh. You won't see a separate work request for the data masking activity, but you can track the status of the refresh activity work request.

The following image shows the data masking option on the Environment refresh page:

You can run data masking as a standalone request. A data masking job can't be submitted for an environment in the following conditions.

You cannot run data masking when:

• A refresh (P2T or T2T) is scheduled or ongoing.
• The environment is currently undergoing maintenance or maintenance is scheduled within 24 hours.
• The Health status of the environment is Unavailable or the Lifecycle state is Updating.

To run data masking for an environment:

1. Navigate to the Environment Details page of the test or development environment.

2. Under Resources, click Security and then click the Data masking tab.

3. Click Run data masking. Confirm that you want to run data masking by entering the environment name.

4. Click Run data masking.

After you submit the job:

• A work request is created. You can monitor the job by viewing the work request.
• The Lifecycle state is updated to Updating.
• The Health status of the environment is updated to Unavailable.
• The Data masking last run date is updated to Running.

The Security tab of the Environment Details page displays the history of data masking jobs run on the environment.

To view data masking history:

1. Navigate to the Environment Details page.
2. Under Resources, click Security.
3. Click the Data masking tab. The previously run data masking jobs are displayed. The table displays the Start Date, End Date, and Status for each job.

Data is masked according to the predefined template provided by Oracle. The following table shows some examples of data masking techniques that are applied.