How do you manage data in your non-prod instances?

[arobertson]

Hi all,

I'm keen to find out how you manage data in your non-production instances when you clone?

* Do you just clone straight from prod keeping all the data?

* Do you not clone that often, so the data is out of date anyway?

* Do you exclude tables when your cloning?

* Do you clone and then run scripts to delete data?

* Do you clone and then run scripts to scramble data?

I'm thinking of it from a GDPR and 3rd party access point of view.

[Moy1 · Accepted solution]

1) From a data security point of view, the best process is to exclude the tables that you know will contain sensitive information. More information on excluding tables, here:

https://docs.servicenow.com/bundle/kingston-platform-administration/page/administer/managing-data/task/t_ExcludeATableFromCloning.html

If you want data for testing purposes then take an xml backup of the excluded table from the sub prod instances.

2) If you need selective data then the only option is to clean up the data post clone. 

https://docs.servicenow.com/bundle/kingston-platform-administration/page/administer/managing-data/concept/post-clone-cleanup-scripts.html

3) for system files, you can use preservers

https://docs.servicenow.com/bundle/kingston-platform-administration/page/administer/managing-data/concept/post-clone-cleanup-scripts.html

[kiranbahl27]

Hello

We implemented security operation in SN. The security Team does not want to copy over data to our nob prod instance. Can you tell me if that is possible and how it is done please. Also would you advise against it? Thank you

[arobertson]

I did also look at scrambling the data using clone scripts but its proving pretty tricky as you need to think about the following.

* On any record where there is a free text field, replace the data with someone else.

* Delete the sys_journal entry's for each record to remove comments/work notes.

* Delete sys_sudit entry's for each record and then disable auditing on each table to not let it show the previous values in the history tab.

 Any guidance would be helpful? maybe i am overthinking it and there is an easier way?

[Moy1]

From a security point of view, the best practice would be to exclude all tables from cloning except for system configuration tables. You can take a xml export of the data from your DEV or TEST instance just before production release and import this data back into the sub-prod environments post clone. The DEV and TEST backups will contain the data and records used for unit and functional testing is therefore, likely to contain a good variety of records.