This topic describes how to enable and run data masking on your Fusion Applications non-production
environments.
Overview of 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.
Data Masking Considerations 🔗
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.
Enabling Data Masking 🔗
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.
Running Data Masking with an Environment Refresh 🔗
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:
Important
After the data masking job is complete, you must run the ESS
processes described in the MOS document: Fusion Global HR: Data Masking Post Processes (Doc ID
2342229.1). Note that this is required for all Fusion Applications
environments, not just Fusion Global HR.
Running Data Masking as a Standalone Job 🔗
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:
Navigate to the Environment Details page of the test or development
environment.
Under Resources, select Security and then select the Data masking tab.
Select Run data masking. Confirm that you want to run data masking by entering the environment name.
Select 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.
Important
After the data masking job is complete, you must run the ESS
processes described in the MOS document: Fusion Global HR: Data Masking Post Processes (Doc ID
2342229.1). Note that this is required for all Fusion Applications
environments, not just Fusion Global HR.
Viewing Data Masking History 🔗
The Security tab of the Environment Details page displays the history of
data masking jobs run on the environment.
To view data masking history:
On the Environments list page, select the environment that you want to work with. If you need help finding the list page, see To list environments.
On the environment details page, under Resources, select Security.
Select 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.
How Your Data is Masked 🔗
Data is masked according to the predefined template provided by Oracle. The following
table shows some examples of data masking techniques that are applied.
Data
Masking Technique
Example Masked Value
Bank Account Number
Random digits
Sample: 4936477859
IBAN
Nulled
<null>
Email addresses
Fixed string
"sendmail-test-discard@oracle.com"
Phone numbers
Random digits
Sample: 925-692-9270 for USA phone number format
Addresses
Address Lines 1 & 2: Fixed String;
Address Lines 3 &4: Nulled;
Postal Code, Town or City, Country: Shuffled as a group
Sample:
Address Line 1: "Station"
Address Line 2: "Road"
Address Line 3: <null>
Address Line 4: <null>
Postal Code: S031 4NG
Town or City: SOUTHAMPTON
Country: UNITED KINGDOM
Dates of birth
Random Date between January 1, 1945 and December 31, 1990
Sample: June 14, 1985
Places of birth
Nulled
<null>
Dates of death
Nulled
<null>
Person names
First Name, Middle Name, Last Name: Shuffled separately from one
another and across persons
Sample: Prabu Ann Chin (masked from original name of Elizabeth Mary
Jones)
Documents of record
From Date: Random date between January 1, 2000 and January 1,
2020;
To Date: Random date between January 1,2000 and January 1, 2020;
Date Issued: Random date between January1, 2000 and January 1,
2020;
Issuing Authority: Random string;
Document of Record ID: Shuffle rows;
Issuing Location: Random string
Sample:
From Date: May 11, 2007
To Date: October 5, 2007
Date Issued: May 9, 2007
Issuing Authority: U#_G
Document of Record ID: TM289384
Issuing Location: I*R@O{C
Disabilities
Table truncated
Driver's licenses
Table truncated
Passports
Passport numbers: Random string
Sample: *K^%KE
Visas and work permits
Visa/Permit Number: Random string; Visa/Permit Type: Shuffle
rows