I'm working up a rough-hewn divestiture plan, and came to realize there's a lot of stuff to uncover. From scrubbing Active Directory data on servers that could leave in an asset purchase, to determining the scope of a password change (and whether or not both sides should endure a password change!), to changing admin- or manager-level passwords and SSIDs on all departing equipment... there's a lot of stuff that must be thought of and properly managed to preserve confidentiality.
My most principal concern would be to prevent AD data (and password hashes for a whole company) to leave in a divestiture. One solution is to force a password change on the remaining company, but I would rather scrub the AD information from departing servers instead. It seems simpler
Anyone have any tips they can share on divestiture planning? Especially in the case of AD. Thanks!
I have to agree with Lamont - there is a lot that depends.
My personal course of action would be to get involved with the deal team and/or the legal department (and make friends with these folks) to understand what they are planning to include in the sale. Ultimately, many of the concerns you have can be front-loaded.
I've been through a number of divestitures and acquisitions and it is quite typical to see AD, servers, VMs, etc, stay with the selling organization and the new organization then spins up new servers they have procured to stand up the necessary environment and import data that is provided (after being reviewed and appropriately sanitized).
To summarize: Get involved early and often, make the legal/deal team aware of the implications, and understand what is being included in the sale.
This is an area where we're working to develop our policy so that it can inform our decisions. Oftentimes, as you may have experienced, IT is something that just creeps from its dark recesses on stakeholder request, and can be easily overlooked until it's too late. This is part of my strategy, in fact, because what is not governed by policy would definitely require hasty decisions.
Funny side note: back in January, our IT director at the time was aware of an acquisition which was scheduled to complete in 75 days. His executive decision was to fully leave IT out of the process until the week before the acquisition took place. It wasn't a funny story at the time, of course.
Stuff like this is why I like asking lots of annoying questions.
This could be a big issue - such as did they deploy an Enterprise PKI system attached to the AD itself, plus did they use other tools such as Sharepoint. My main concern would be exactly where, what, how and who has access to the current organisation data, and has it been classified, categorised and who is authorised to see that data. How will you ensure that any residual data, whether under contractual agreements, is not accessed by the remaining company or is being accessed by unauthorised personnel. How will you ensure that all systems residual data has been suitably cleansed, and confirm to be sanitised? Which may include metadata, in various formats and types i.e. unstructured and structured data.
What about the actual systems themselves i.e. servers physical, virtual memory, storage systems and any other places where data could reside without peoples full knowledge over time.
Plus you can add paper records, electronic records, databases, and any off line storage systems as well.
@ericgeater, ensure that the scope is properly defined --- if you miss out anything and have to deal with it at the last moment, things are likely to get overlooked.
The policies of both the organization getting rid of assets & the one acquiring them will have to be considered & enforced as needed, lest there be unwanted consequences.
And I can't stress enough on the need for documentation. If this isn't being maintained properly, there will be a host of problems at all stages.
Nowadays, IT is integrated into everything, so someone from your team should be involved at the start. Alas, it doesn't always happen that way --- I've often seen projects agreed on at the top level, & then just 'dumped' on IT, with the result that they lag or eventually fail.
I'm sure you've already done a good lookup for info on this; if not, here are 2 sources that might be useful: -