Wise IT, IT done wisely
Client support Let’s talk

IT assessment guide

What should a useful IT assessment cover?

An assessment should explain what the business depends on, where the important risks and support gaps are, and what to do next. This checklist helps you gather the evidence without turning the exercise into a product inventory.

By

Begin with the reason for the assessment

A broad request to “review IT” can produce a long list with no clear priority. Write down the decision or concern that prompted the work. The assessment may support a budget, provider change, acquisition, office move, security review, recovery plan or a response to recurring failures.

Record the people who need the result and the decisions they expect to make from it. A finance leader may need cost and lifecycle visibility. An operations leader may care most about interruptions and ownership. The technical team will need enough detail to validate findings and carry out the work.

1. Business services and impact

Technology risk has meaning only in the context of the work it supports. Start with the services customers and employees depend on.

  • Which business activities create revenue, meet an obligation or keep people safe?
  • Which applications, data, facilities and outside providers support each activity?
  • When are the busiest or least flexible operating periods?
  • What happens after an hour, a day or several days without the service?
  • Which planned changes could alter these dependencies?

This context gives the rest of the checklist a sensible order. It also prevents a visually impressive system from receiving more attention than a quiet dependency the business cannot operate without.

2. Systems, data and lifecycle

Build an inventory that is detailed enough to assign ownership and make decisions. The goal is a usable view of the environment, not a count for its own sake.

Capture the basics

  • Locations, users, devices, servers, network equipment and critical peripherals
  • Cloud services, business applications, domains, certificates and data stores
  • Operating systems, important versions, warranty and support status
  • Licenses, renewals, contracts and known end-of-life dates
  • System owners, administrators, vendors and escalation contacts
  • Connections between systems, including file transfers, integrations and manual workarounds

Compare the written inventory with billing records, identity directories, network data and what staff actually use. Differences are findings. An unknown subscription or unsupported server can reveal missing ownership even when it is still working.

3. Identity and administrative access

Find out how people and service accounts receive access, how privileges are approved and how access is removed. Pay special attention to accounts that can change security settings, billing, backups, domains or network infrastructure.

  • Is multi-factor authentication required where the service supports it?
  • Are administrator accounts separate from ordinary daily-use accounts?
  • Can the business identify all privileged users and service accounts?
  • Are shared accounts limited, justified and protected?
  • Does offboarding cover local systems, cloud services, vendors and physical access?
  • Is emergency access documented and periodically checked?

Ask who controls the primary domain, tenant, password vault and recovery contacts. The business should be able to regain control without depending on one employee or supplier.

4. Network, cloud and data paths

Review how users, locations, applications and vendors connect. A current diagram should show internet circuits, firewalls, important network segments, wireless services, remote access and key cloud dependencies.

  • Are business, guest, voice, camera and management networks separated where appropriate?
  • Who can administer the network, and from where?
  • Are carrier details, circuit identifiers and escalation paths recorded?
  • Do monitoring records help explain capacity, instability and recurring incidents?
  • What happens to calling, authentication and cloud applications when a circuit fails?
  • Can the team trace important data as it moves between internal and external systems?

For a deeper review, see Wise IT's network infrastructure consulting approach.

5. Security controls and operating habits

Review what is in place, who maintains it and how the organization knows it is working. The NIST Cybersecurity Framework provides a useful common language for governing, identifying, protecting, detecting, responding to and recovering from cybersecurity risk.

  • How are updates, vulnerabilities and unsupported systems handled?
  • Which endpoint, email, identity, network and cloud security controls are active?
  • Who reviews alerts, and what triggers escalation?
  • Are logs available for the systems most likely to matter during an investigation?
  • How is vendor access approved, limited and removed?
  • Do incident contacts and response steps exist outside the systems they may need to recover?

Evidence matters. A purchased license does not prove that a control is deployed, configured well or monitored.

6. Backup, recovery and continuity

List the data, configurations and services the organization expects to recover. Then compare that expectation with actual backup coverage and restore evidence.

  • What is backed up, how often and for how long?
  • Can a compromised production account alter or delete the protected copies?
  • Which cloud applications need separate backup or export procedures?
  • What are the recovery time and data loss goals for critical services?
  • Which identity, network, vendor and facility dependencies are required to restore service?
  • When was the last realistic restore test, and what did it prove?

The backup and recovery testing guide explains how to turn these questions into a practical exercise.

7. Support, vendors and daily operations

Technology can be technically sound and still be hard to operate. Review how work enters the queue, who owns each category and how recurring trouble leads to improvement.

  • Where do users request help, and can the business see status and history?
  • Which systems have no named owner or documented escalation path?
  • Are recurring incidents investigated beyond the immediate fix?
  • How are changes approved, scheduled, tested and recorded?
  • Do vendor agreements match the responsibility people assume they provide?
  • Can another qualified person use the existing documentation during an absence?

Review a sample of recent incidents, changes and vendor escalations. Real work often reveals more than a policy document.

Turn observations into decisions

A finding should keep facts and judgment separate. Use a simple structure:

  • Observation: what the assessor saw or could not find
  • Evidence: records, configuration, interviews or test results supporting it
  • Business effect: the service, obligation, cost or risk involved
  • Recommendation: the proposed action and why it is suitable
  • Priority and owner: when it should be addressed and who decides
  • Verification: how the organization will know the work succeeded

The final report should distinguish urgent exposure from lifecycle work and longer-term improvement. It should also identify decisions that require more evidence instead of presenting every uncertainty as a fact.

After the assessment

Put the findings into an order the business can carry.

Some findings need a quick correction. Others belong in a funded project, operating agreement or longer-term roadmap. Give each item an owner, dependency, target decision and way to verify completion.

The technology roadmap guide shows how to organize that next step. If you need an independent review, see what Wise IT includes in a scoped IT environment and ownership review.

Need an independent look at the environment?

Wise IT can shape an assessment around the decision you need to make and explain the result in business and technical terms.

Talk about an IT assessment