The following actions are part of the data masking process:

The following actions are part of the data masking process:

A.
Re-create masked table copy & populate using renamed original table and mapping table.

B.
Disable constraints on table & rename table.

C.
Build mapping table containing original sensitive and masked values using masking routines.

D.
Drop renamed table and mapping table.

E.
Restore constraints based on original table & collect statistics.
In which order are these actions performed?

F.
A-B-C-D-E

G.
E-D-C-B-A

H.
A-C-E-B-D

I.
C-B-A-D-E

J.
C-A-B-E-D

Explanation:
The following basic steps guide you through the data masking process, with references toother
sections for supporting information.

Review the application database and identify the sources of sensitive information.
Define mask formats for the sensitive data. The mask formats may be simple or
complexdepending on the information security needs of the organization.
For more information, see “Creating New Masking Formats” and “Using Oracle-supplied
PredefinedMasking Formats”.
Create a masking definition to associate table columns to these mask formats. Data
maskingdetermines the database foreign key relationships and adds foreign key columns to
themask.
For more information, see “Masking with an Application Data Model and Workloads”.
Save the masking definition and generate the masking script.
Verify if the masked data meets the information security requirements. Otherwise, refine
themasking definition, restore the altered tables, and reapply the masking definition until
theoptimal set of masking definitions has been identified.
Clone the production database to a staging area, selecting the masking definition to be usedafter
cloning. Note that you can clone using Enterprise Manager, which enables you to addmasking to
the Enterprise Manager clone workflow. However, if you clone outside ofEnterprise Manager, you
must initiate masking from Enterprise Manager after cloning iscomplete. The cloned database
should be controlled with the same privileges as theproduction system, because it still contains
sensitive production data.
After cloning, be sure to change the passwords as well as update or disable any databaselinks,
streams, or references to external data sources. Back up the cloned database, orminimally the
tables that contain masked data. This can help you restore the original data ifthe masking
definition needs to be refined further.
For more information, see “Cloning the Production Database”.
After masking, test all of your applications, reports, and business processes to ensure theyare
functional. If everything is working, you can export the masking definition to keep it as aback-up.
After masking the staging site, make sure to drop any tables named MGMT_DM_TT beforecloning
to a test region. These temporary tables contain a mapping between the originalsensitive column
value and the mask values, and are therefore sensitive in nature.
During masking, Enterprise Manager automatically drops these temporary tables for you withthe
default “Drop temporary tables created during masking” option. However, you canpreserve these
temporary tables by deselecting this option. In this case, you are responsiblefor deleting the
temporary tables before cloning to the test region.
After masking is complete, ensure that all tables loaded for use by the substitute columnformat or
table column format are going to be dropped. These tables contain the maskvalues that table

column or substitute formats will use. It is recommended that you purge thisinformation for security
reasons.
For more information, see “Deterministic Masking Using the Substitute Format”.
Clone the database to a test region, or use it as the new test region. When cloning thedatabase to
an external or unsecured site, you should use Export or Import. Only supply thedata in the
database, rather than the database files themselves.
As part of cloning production for testing, provide the masking definition to the applicationdatabase
administrator to use in masking the database.