Privileged Access After the Merger

Sequence: (1) inventory and ownership - disable the 380 orphaned accounts and shared credentials that are no longer needed; this is low-cost risk reduction. (2) Establish one authoritative identity source and a joiner/mover/leaver process; consolidate the four identity providers in waves, starting with the acquired company's non-privileged workforce. (3) Deploy privileged access management: vault the 1,700 privileged accounts, rotate credentials, remove standing admin rights, and add time-bound check-out. (4) Only then expand user behavior analytics, after privacy consultation. Privileged access comes before behavior analytics because it reduces the highest-impact risk and because the analytics tool needs clean identity data to be useful. Nine months is tight but feasible if the first two waves are limited to high-risk accounts and the German subsidiary is handled after consultation. Publish a dependency plan, because identity provider consolidation will break applications that rely on local accounts.

I would tell the board member that terminating the flagged accounts now would be a legal and evidentiary mistake. The works council has co-determination rights over monitoring, and acting on monitoring data before consultation can invalidate the investigation, expose the company to labor claims, and create a GDPR problem. It also risks the insider case itself: if the evidence is obtained improperly, it may be unusable in a dismissal or criminal referral. The right approach is proportionate: complete the data protection impact assessment, consult the works council, limit analytics to metadata rather than content where possible, restrict access to alerts to a small investigations team, and route high-confidence cases through HR and legal. In parallel, protect the data with technical controls that do not depend on monitoring individuals - data loss prevention, blocked personal cloud uploads, and least privilege. That answers the board's real concern, which is data loss, without 'sorting out privacy later.'

Do not remove all 60 shared credentials at once; a plant outage is a real safety and business risk. Put them under a password vault with check-out, so each use is tied to a named individual even if the underlying account is shared, and rotate the password after each check-out or at least every 24 hours. Move to unique local administrator passwords per host using a local administrator password solution, then remove standing local admin rights from users. For legacy systems that cannot support unique credentials, isolate them in a management VLAN with jump hosts, restrict who can check out the credential, and log sessions. Add break-glass accounts with sealed credentials for emergencies. Set a 90-day milestone to reduce the 60 to a documented exception list, and a 180-day milestone to eliminate shared credentials on systems that support unique accounts. Operations must co-own the plan; security cannot impose it unilaterally.