Вы находитесь на странице: 1из 5


Fusion Applications

FAQ on Data Masking in Fusion Applications

Nitin Jain
Data Masking

What is Data Masking?

Fusion data masking is a process of applying a pattern or algorithm designed to scramble data in a
non-production environment with the goal to reduce exposing personal data (also known as
personally identifiable information or PII) to unauthorized people.

Why Data Masking?

Fusion data masking process is designed to mask specific entities and fields in non-production
environments in a way that is designed to protect the original data from being exposed while
maintaining production-like views.

What is Data Masking Process?

The masking process would be initiated by creating a Service Request (SR) either as part of a P2T
(Production to Test) refresh request or as a standalone request for data masking. The Cloud
Operations team uses the Production-To-Test or P2T process to create a customer’s non-production
environment with data from their production environment, if P2T refresh is requested.

Once the non-production environment has been refreshed (where P2T refresh is requested) or once
the non-production environment is identified (by the customer) for data masking, the Cloud
Operations team will target to run the data masking scripts on the non-production environment, using
Enterprise Manager Cloud Control tool. Data masking is intended to run promptly after the
environment refresh (in cases where data masking is requested as part of a P2T request) and the
environment can be expected to be released for customer access after data masking is complete.

Is data masking available to all customers?

No. Data masking is available only to ERP, HCM, Sales Cloud Service customers with a paid subscription
to the Data Masking for Fusion Cloud Service. You need to contact your Oracle Account Team to
subscribe to this service.

What are the various options available for data masking?

There are couple of options. The first option is the most common where a customer requests data
masking as part of an environment refresh. This assures that the production data you’ve migrated to
a non-production environment via the refresh is masked before you provide your users with access to
it. The second option is less common where you will request standalone data masking if you have 1)
loaded real Person information from another system directly into your Fusion non-production
environment or 2) previously migrated data to your non-production environment via an environment
refresh and subsequently wish that data to be masked.

Can I make changes to data that has been masked?

Yes. Any changes you make to masked data will be saved to the database as long as the changes pass
system edits. This modified data will not be re-masked.

Can I request that data be masked exactly how I want it?

No. There is no option to customize what data is masked or how that data is masked.
After our data is masked, will it be possible for someone to figure out who’s who on the database?
If yes, why?

Possibly. Even though personally-identifiable information (PII) is masked, you must continue to
practice good data governance and restrict access to masked data to only those persons whose jobs
require it. A determined user could figure out a person’s identity through a combination of non-PII
data (for example, location, job, and gender). If we were to mask data to avoid this from happening,
the resulting data would not be useable for user acceptance testing and several consistency edits
within the applications could break. Use data security to restrict the data that a user can see.

Can I request that data be masked exactly how I want it?

No. There is no option to customize what data is masked or how that data is masked.

Do not request the data masking service if:

–Your intent is to replicate the same results as when using real, unmasked data. Key examples are
payroll calculation and any process that uses data input values that would be modified by the data
masking process.

–Your test purpose is to verify interfaces to downstream system that require real data that is not

- Please be sure to analyse and consider potential impact to your intended test purpose, scope and
downstream processing.

Limitation with Project Financial Management:

–For Project Financials Cloud service, there is a known limitation where data must remain unmasked
to preserve the integration with Commitment Control (XCC).

–After data masking is applied, resource names defined in the planning, billing, and reporting resource
breakdown structures remain unmasked but can contain PII, such as person names that unauthorized
users must not see.

What are masking Entities?

Fusion data masking process is designed to mask certain sensitive personal data or PII attributes listed

 Person Name
 Person Telephone Number
 Date of Birth
 Date of Death
 Country / Town / Region of Birth
 Address
 Bank Account Name
 Bank Account Number
 Credit Card Number
 Instant Messaging Address
 Email Address
 Passport Number
 Visa Number or Work Permit
 Tax Registration Number or National Taxpayer Identifier
Fusion masking process is also designed to remove the following items from the masked database:
 Workflow notifications
 Audit data from audit shadow tables
 Data from interface tables and temporary tables

How data will be Masked?

Data Masking Technique Masked Value

Bank Accounts Random Digits Sample: 4936477859
Email Addresses Fixed String “sendmail-test-
Phone Numbers Random Digits; USA phone Sample: 925-692-9270
number format
Addresses Address Lines 1 & 2: Fixed Sample:
String; Address Lines 3 &4: • Address Line 1: “Station”
Nulled; • Address Line 2: “Road”
Postal Code, Town or City, • Address Line 3: <null>
Country: Shuffled as a group • Address Line 4: <null>
• Postal Code: S031 4NG
• Town or City:
Dates of Birth Random Date between January Random Date between January
1, 1945 and December 31, 1990 1, 1945 and December 31, 1990
Places of Birth Nulled <null>
Dates of Death Nulled <null>
Person Names First Name, Middle Name, Last Sample: Prabu Ann Chin
Name: Shuffled separately
from one another
Documents of Record From Date: random date Sample:
between January 1, 2000 and • From Date: May 11, 2008
January 1, 2020; To Date: • To Date: October 5, 2007
random date between January • Date Issued: July 9, 2003
1, 2000 and January 1, 2020; • Issuing Authority: U#_G
Date Issued: random Date • Document of Record ID:
between January 1, 2000 and TM289384
January 1, 2020; Issuing • Issuing Location: I*R@O{C
Authority: random string;
Document of Record ID: shuffle
rows; Issuing Location: random
Disabilities Table truncated ---
Driver’s Licenses Table truncated ---
Passports Passport Numbers: random Sample: *K^%KE
Visas/Work Permits Visa/Permit Number: random Sample:
string; Visa/Permit Type: • Visa/Permit Number:
shuffle rows K%R+KH@
• Via/Permit Type: Academic
National Identifiers Table truncated --
Termination Dates Nulled <null>