Due diligence – weaknesses

Home Forums Due Diligence Due diligence – weaknesses

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #139733
    Anonymous
    Inactive

    Due diligence allows the buyer to access to a wide range of information about the target company. Which topics do you think can not be properly addressed and which risks not fully evaluated or identified during due diligence process?

    #140030
    Anonymous
    Inactive

    The biggest weakness to due diligence is not having a complete requirements list for each functional area who are participating in the diligence. This allows you and the seller to be working off of on document and the seller knows that the asks are and you have a tracking tool for what has been received and what is still outstanding. This can also help you track the percentage of completion and any follow-up questions your teams might have.

    #140180
    Anonymous
    Inactive

    Assuming we’re talking about pre-acquisition due diligence, there are definitely limitations when it comes to evaluating the target company’s IT environment.

    For starters, there’s often a natural reluctance from the target’s IT team to provide detailed infrastructure or security information. That hesitation isn’t misplaced. Disclosing too much can pose legitimate security risks, especially if the deal doesn’t go through. So what you typically get is a high-level view, maybe some architecture diagrams, licensing summaries, and general system overviews—but rarely enough detail to assess operational maturity or technical debt with confidence.

    Another common blind spot is fragmentation within the target’s IT function. If the organization is decentralized or operating under a business unit model, not all IT personnel will be looped into the due diligence process. This leads to gaps in responses, and sometimes critical environments or legacy systems aren’t even identified until post-close.

    Risks I’ve seen that are often under- or un-evaluated during IT due diligence include
    – Unsupported or end-of-life infrastructure (especially at remote or acquired sites)
    – Hidden custom applications or integrations that aren’t centrally tracked
    – Shadow IT—SaaS tools or third-party services used outside formal IT control
    – Overstated licensing positions (e.g., compliance issues masked by manual tracking)
    – Incomplete or nonexistent DR/backup processes
    – Security vulnerabilities or poor identity governance that aren’t disclosed unless there’s a formal audit

    To mitigate this, I’ve found value in creating a post-close discovery phase as part of the integration plan. In this we revisit IT assessments in a structured way with full access. It’s essentially due diligence 2.0, but with fewer restrictions and better visibility.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.

Are you sure you
want to log out?

In order to become a charterholder you need to complete one of the IMAA programs