Thirty-Day Identity Integration After an Acquisition

The normal elicitation route (workshops, documented processes) is unavailable: there are no JML records and the knowers leave on day 45. I would shift to evidence-based elicitation.

• Data analysis first. Export the AD objects and analyse attributes - last logon, password last set, manager field, description, group membership, SPN and service-account flags. The 610-versus-400 gap and the 38 orphaned contractors are findings, and each finding becomes a requirement clause with a measurable condition (e.g. accounts with no logon in 90 days and no valid sponsor shall be disabled before migration).
• Document analysis of the acquisition agreement, payroll schedule and Corvus's identity standard, to fix the non-negotiables and the dates.
• Job shadowing and short interviews with the three IT staff, prioritized by what only they know: the 22 service accounts. Capture owner, purpose, credential location and dependency for each while the knowledge still exists.
• Record assumptions and their expiry. Anything unresolved at day 45 becomes an assumption with a named Corvus owner - not an open question with no owner.
• Validate by walkthrough with the payroll team, because payroll on the 25th is the constraint that will break any elegant design.

The risk is that a clean-slate approach disables something payroll depends on. The requirements should therefore separate categorization from removal.

Contractors (38, sponsor gone):

1. Every enabled account shall have a named, currently employed sponsor recorded in the directory. Fit criterion: an extract showing zero accounts without a valid sponsor.
2. Accounts failing criterion 1 shall be disabled, with the disablement logged and notified to the former sponsor's manager and to the contractor's agency contact.
3. Re-enablement requires a new sponsor and a manager attestation - this stops the reflexive re-enabling that follows every bulk disablement.

Service accounts (22, unknown ownership):

1. Each service account shall have a documented owner, consuming application, and credential custody record before migration.
2. Before ownership is established, service accounts shall be migrated as-is but placed in a monitored group, with authentication failures and interactive logons alerted - this is the compensating control that keeps payroll running.
3. Interactive logon by a service account shall be denied, which is testable and does not change the account's password or SPN.

Constraint: changes to payroll-touching accounts are frozen from the 20th to the 26th. That constraint is a requirement input, not an excuse to skip the work - it moves the cutover date for those objects.

This is a need-to-know requirement, not a role requirement, and it must survive the fact that the retained staff are still employed and still need to do their jobs.

Requirements:

1. Retained staff shall be provisioned only into a role whose entitlements are limited to the transition-scope systems, with the role defined explicitly rather than by removing items from a broader role (removal-based design leaks when new entitlements are added later).
2. Access to pricing data shall be denied by policy at the data layer, not only by hiding menu items, with a fit criterion that a direct request to the pricing repository by a retained-staff account is refused and logged.
3. Retained-staff accounts shall be reviewed monthly by the Corvus transition manager, not quarterly, because the standard review cadence is too slow for a six-month, conflict-of-interest population.
4. Access shall expire automatically on the TSA end date, with no manual step required.

Validation: a negative test for each data domain named in the TSA (attempt access with a retained-staff account, confirm refusal and log entry), plus a reconciliation that the account list matches the TSA schedule and the HR leaver report. Validation is done by someone outside the migration team; the migration team testing its own controls is the failure mode that regulators find.