Remove personally identifiable information during system clone

[jamesdecker]

The company I work for is nearing go-live date for ServiceNow, and as both a business and technical SME for the project I've been working on some policies and procedures to be used going forward within our company for development, administration, etc.

Our company is pretty big on protecting information these days (what company isn't?), and one thing that keeps going through my mind is how to handle the cloning of production back into development instances.

I've done system clones before, and I can see there's the ability to run scripts as a part of the clone, as well as exclude tables, etc. Before I go re-inventing the wheel, has anyone made a pretty robust way of cloning a production instance to a development instance, but altered personal information in a way where it is no longer sensitive? 

For example, taking Incident, we'd want to alter first and last name, phone, email etc. on callers to be from a selected list of maybe 100 "personas", then doing the same with incident title and description, etc. so that the quantity of data, the sys_ids, relationships, etc. all remains, but the specific information itself is lost. This is what we currently do for some other in-house applications, as per the requirements of our information security team.

[Chuck Tomasi]

For me, this brings up a lot of questions and gets in to the "technology vs. training" thing.

Your developers and admins are in a position to access information. They need that information to do their jobs. If they aren't trained how to properly handle that information, they shouldn't be in that position. Have them sign a legal document (or NDA or something) stating that they know how to handle that data and will not release anything with PII.

If you have information, like Salaries, that you don't want others seeing, don't put it on the system. 🙂 If it needs to be on the system to drive a process, consider encrypting it so that only people who need to see that information can read the encrypted information (as long as it doesn't interfere with the business logic of the process.) E.g. don't encrypt reference fields or fields that need to be compared values in a script.

After thinking about the solution of running a post-clone script to "anonymize" the data, I don't think this is fool proof. If I were to take the sys_user table and scramble the letters of "Chuck Tomasi" so that it reads "xD8ff3 992x" (not using encryption), it wouldn't take much for a smart person to poke around tables and perhaps see what assets belong to that sys_user account to figure out who it really is.