The first thirty days after close are when known weaknesses stop being findings and become operating conditions owned by the buyer. The target is distracted. Advisers depart. Credentials have crossed deal rooms. Vendors are waiting for new instructions. Integration teams want connectivity. Staff are uncertain which rules now apply. An attacker already present in the environment does not observe a ceremonial boundary at completion. This period should not be filled with an undifferentiated transformation programme. It needs a control sequence.
Hours 0–24: preserve and establish command
- Confirm the named decision authority for technology, security, legal escalation and external communication.
- Preserve transaction-period evidence, security logs and known incident records under an appropriate legal and operational process.
- Freeze unnecessary changes to privileged access, logging, retention and critical integrations.
- Validate emergency contacts and independent communication channels.
- Identify the systems whose failure would stop cash, safety, customer service, regulated activity or executive communication.
The purpose is not to change everything. It is to prevent loss of evidence and ambiguity of command.
Days 1–3: close the obvious transfer gaps
- Remove or suspend access tied to sellers, departed personnel and temporary transaction teams unless explicitly retained.
- Change recovery contacts and validate control of primary domains, cloud tenants, code repositories, security platforms and financial applications.
- Rotate exposed high-consequence credentials using a sequence that respects machine dependencies.
- Confirm that monitoring is operating and alerts reach people who now have authority to respond.
- Notify critical vendors of the verified new authority and reject instruction changes received through unverified channels.
Document every exception. A credential that cannot yet be rotated is not invisible; it becomes a named exposure with compensating controls and a deadline.
Days 4–10: test the operating truth
Compare diligence representations with live reality.
- Sample privileged access and service accounts in the actual systems.
- Test restoration of one critical service or data set.
- Trace a high-value instruction from request through approval, execution and reconciliation.
- Review current vulnerabilities in internet-facing and identity infrastructure.
- Check whether unsupported systems or undocumented integrations sit inside critical workflows.
- Interview the people who handle failures after hours; they often know the real dependencies.
Do not turn this into a comprehensive audit. Focus on conditions that can create immediate loss or invalidate the integration plan.
Days 11–20: contain before connecting
Group findings into four actions:
- Isolate: keep the system or identity outside the buyer’s trust boundary.
- Constrain: reduce privilege, connectivity, data flow or permitted use.
- Observe: improve logging and define triggers for intervention.
- Correct: remediate now where the risk and dependency are understood.
Every proposed integration should have entry criteria. Shared identity, network links, data migration and common administration should not proceed merely because the programme plan contains a date.
Days 21–30: convert emergency control into ownership
- Approve a prioritised remediation and integration plan tied to business outcomes.
- Assign budget, accountable executives and technical owners.
- Translate material diligence items into closing-condition evidence, covenants, claims or reserved rights where applicable.
- Confirm incident notification, insurance and regulatory pathways.
- Establish the ongoing metrics: privileged access, identity recovery, critical vulnerabilities, recovery evidence, vendor concentration and open exceptions.
- Brief the board or investment authority on thesis collisions, not a raw catalogue of defects.
Three traps
First, do not confuse activity with control. Hundreds of tickets can be open while nobody can revoke the primary cloud administrator. Second, do not let the target mark its own diligence findings closed without buyer evidence. Third, do not force the buyer’s standard stack into an environment whose dependencies are not understood. A security tool that causes an outage is still an operating failure.
What good looks like on day 30
The buyer may not have remediated every material weakness. It should know which exposures exist, who owns them, which connections are prohibited, how critical authority is recovered and how an incident would be commanded. The first month is successful when inherited uncertainty has been converted into explicit control decisions. Technology risk became yours at close. By day thirty, it should no longer be anonymous.