IT Risk Assessment: How to Run One That Holds Up

The annual assessment lands on your desk. You export the asset list, and before you’ve opened the risk register, you already know the export is wrong.

Nobody updated it after the last tech left. There are machines listed that were decommissioned in March, two loaned to a contractor who finished in April, and a laptop a manager swears was returned. You clean up what you can, tell yourself it’s close enough, and move to step two.

That’s where most IT risk assessments quietly go wrong. Not in the scoring, not in the framework you picked, but in the list everything else is built on. A risk assessment inherits the accuracy of its asset inventory. If that inventory is a spreadsheet nobody trusts, what you’re producing is a document, not an assessment.

This guide covers the process end to end: scoping, verifying your inventory before you assess anything, scoring risk without inventing numbers, turning findings into controls someone owns, and what belongs in the report your auditor and your boss will both read.

What an IT risk assessment actually is (and what it isn’t)

Ask three people in your organization what a risk assessment is and you’ll get three answers: a scan, an audit, and a spreadsheet.

An IT risk assessment identifies the technology assets your organization depends on, the threats and vulnerabilities affecting them, and the business impact if they’re compromised. It produces a prioritized list of risks, each with a named owner and a decision: mitigate, transfer, accept, or avoid. That decision is the output. Not the score.

A vulnerability scan tells you what’s technically wrong: unpatched software, open ports, weak configurations. It’s an input to the assessment, not the assessment itself. A scanner can tell you a laptop is missing a critical patch. It can’t tell you that the laptop belongs to the person who handles payroll.

A compliance audit checks whether you did what you said you’d do, measured against a standard. A risk assessment is what tells you which standards and controls you should care about in the first place.

An asset inventory is the foundation, not the product. This is the confusion worth naming, because it’s the most common one. A line that circulates in security circles puts it well: the board thought it had a risk assessment; it had a technical inventory. A list of what you own, with no threat analysis and no business impact attached, is an asset register wearing a different hat.

Timing matters too. Annual cadence is the norm, but the real trigger is change: a new office, a cloud migration, a merger, a shift to hybrid that put 200 laptops outside your network. If your environment changed materially and you haven’t reassessed, your register describes an organization you no longer run.

Before you start: scope, ownership, and the inventory problem

Here’s a number worth sitting with. Across Prey’s demo calls, roughly a quarter of IT teams say they manage their fleet in a spreadsheet, and they volunteer that it’s out of date without being asked. One consulting firm in Chile described it plainly: they manage the inventory of about 90 computers in an Excel sheet. Not as a confession. As the status quo.

That’s the environment most assessments start in.

Scope by business process, not by device count. “All company laptops” sounds like a scope, but it gives you no way to prioritize. “The systems and devices involved in processing customer payment data” gives you a boundary, a data classification, and a reason to care. Start from the processes the business can’t lose, then work outward. Include where the data lives, not just the hardware holding it.

Scope also decides what you’re not assessing. Server room access, unattended workstations, and who can walk out of the building with a device are physical controls. Leaving them out deliberately is a decision; leaving them out by accident is a gap.

Assign ownership before you assess anything. Every asset category needs a name attached: endpoints, SaaS accounts, servers. Not for blame. At the treatment stage you’ll need someone who can approve a change, and discovering there’s no owner then stalls the cycle.

Then reconcile the inventory, and treat the gap as a finding.

This is the step nearly every guide skips. You have a documented inventory: the spreadsheet, the procurement records, the asset tags. And you have an observed inventory: the devices that have actually reported in recently. They rarely match, and the difference is not an administrative annoyance. It’s your first result.

An IT manager at a 300-device organization exports the spreadsheet for the annual assessment: 312 machines. The endpoint agent shows 287 devices reporting in the last 30 days. Some were decommissioned and never removed, two went to a contractor whose engagement ended, and three nobody can place at all. Those last three aren’t a data quality problem. They’re unaccounted devices that may still hold company data. The same pass surfaces what nobody registered in the first place: personal devices on company mail, the warehouse machine on an unsupported OS, the SaaS tool a department expensed directly. Shadow IT isn’t an exception to your scope; it’s a category inside it.

Quick win: Export your asset list and cross-reference it against devices that have checked in within the last 30 days. Log the difference as finding #1, before you assess a single threat. If you can’t produce the second list at all, that’s the finding.

How endpoint visibility platforms close the inventory gap

Reconciling a documented list against an observed one requires a live source of truth. That’s a specific capability: an agent on each device reporting hardware and software inventory, last-seen timestamps, encryption status, and location, in one view across mixed operating systems.

In practice the workflow is unglamorous. You pull the fleet view, filter for devices with no check-in in 30 days, and you have your discrepancy list in minutes instead of a week of emails. From there you can act: locate what’s misplaced, lock what’s unaccounted for, retire what’s genuinely gone, with a timestamped record of each action.

Prey is one platform built for this, and it tends to fit teams running Windows, macOS, Linux, Android, iOS, and Chromebooks side by side without a dedicated asset management function. A reviewer from a government administration organization on G2 put it in operational terms: “In terms of inventory management and security, it meets all the necessary requirements without complications.”

The point isn’t the tool. It’s that asset visibility has to come from something that observes, not something you maintain by hand. A spreadsheet can only tell you what someone remembered to type.

How do you perform an IT risk assessment, step by step

Most step-by-step guides read like they were written for an organization that already has its house in order. Here’s the version that assumes you don’t.

There are five steps: verify the asset inventory, identify threats and vulnerabilities per asset, estimate likelihood and impact, decide a treatment for each risk, and document the result with an owner and a date. Most assessments fail at step one, not step three.

Each step produces something. If a step doesn’t leave an artifact behind, you skipped it.

Step 1: Verify the inventory. Covered above. The artifact is a reconciled asset list plus a documented gap.

Step 2: Identify threats and vulnerabilities per asset. Threats are what could act against the asset; vulnerabilities are what make it susceptible. Work per asset category rather than enumerating every cyber threat in the abstract. For endpoints: theft and loss, unencrypted local storage, missing patches, credential reuse, devices that never come back from a departing employee. Your endpoint vulnerability data and software inventory feed this step; they don’t replace the judgment part.

Take one risk through the whole process, because a real one is easier to reason about than a category. A field sales laptop holds local copies of client contracts. It travels weekly. Encryption status shows “unknown” in your console because the device hasn’t reported since the user stopped connecting to the VPN.

Step 3: Estimate likelihood and impact. Next section. The artifact is a scored register.

Step 4: Decide a treatment. For the field laptop: mitigate. Enforce encryption, confirm the device reports independently of the VPN, and shorten the check-in threshold that triggers an alert.

Step 5: Document, with owner and date. Every risk gets a person and a review date. A register with 40 risks and no owners is a list of things nobody is doing.

On methodology, NIST SP 800-30 and ISO 27001 are the two common reference points, and ISO 27001 control A.5.9 is the one that makes asset inventory an explicit requirement rather than a suggestion. Pick one and stay consistent so you can compare cycle over cycle; choosing between them is its own conversation about risk management frameworks.

Quick win: Take one asset category through all five steps before you scale up. If you can’t produce a scored, owned, dated entry for a single laptop, the process isn’t ready for 300 of them.

How do you score risk without making up numbers

Scoring is where assessments start feeling like theater. Someone says “that’s probably a 4,” it goes in the cell, and six months later nobody can reconstruct why.

Score each risk as likelihood times impact on a 5×5 matrix. Likelihood comes from observed frequency: incidents you’ve actually had, plus industry base rates for the ones you haven’t. Impact comes from business cost, not technical severity. Write down the reasoning behind each score. That reasoning is what an auditor challenges, not the number.

Start from your own history. How many laptops did you actually lose last year? A K-12 district running a 1:1 program typically loses four or five devices a year out of a couple thousand. If that’s your environment, “loss of a managed laptop” isn’t a 2 on likelihood; it’s a 4 or a 5, because it isn’t hypothetical. It happened, and you have the tickets to prove it.

Impact is where the discipline lives. Define your bands in currency before you score anything. A breach affecting 500 customer records has a cost you can estimate from notification requirements, credit monitoring, legal review, and staff hours. “High” is not a band. “$50,000 to $250,000” is.

Run the field sales laptop through it. Likelihood: devices in the field get lost, you had two incidents in eighteen months across 40 field users, call it 4. Impact: client contracts stored locally, unverified encryption, a notification obligation if the data turns out to have been accessible, call it 4. Score 16 out of 25, top tier, and the reasoning fits in two lines a non-technical reader can follow.

Reserve quantitative methods, assigning explicit monetary values to loss expectancy, for your handful of highest-value risks. Qualitative scoring is fine for the rest; monetizing all 60 entries produces false precision and a register nobody finishes. The mechanics of the matrix itself are covered in the risk matrix guide.

Quick win: Before your next scoring session, write your impact bands in actual currency and pull the incident count from your ticketing system for the last 24 months. Both take under an hour and remove most of the argument from the room.

Turning findings into controls that actually get implemented

The register is done, it has 47 entries, and three months later the same 47 entries show up in the next cycle with the same scores. This is the most common failure after the inventory one, and it’s a process failure, not a technical one.

Every risk gets one of four decisions: mitigate it with a control, transfer it (usually through cyber insurance), avoid it by retiring whatever creates the exposure, or accept it deliberately.

Accepting risk is legitimate, and treating it as failure is why registers stagnate. If the cost of mitigation exceeds the plausible loss, acceptance is the correct answer. The requirement is that it’s documented, signed by someone with authority to accept it, and given a review date. Undocumented acceptance is just an ignored risk with better paperwork.

For each mitigation, record the control, the owner, the target date, and what closure evidence looks like. “Enforce encryption on field laptops” isn’t closeable. “BitLocker enabled and reporting compliant on all 40 field devices, verified via encryption status report, owner: Marcos, due March 15” is.

One control category deserves attention because teams consistently overstate it: response capability. “We have remote wipe” is a policy statement. “Remote wipe completes in under X minutes from the moment we’re notified” is a control you can score. An MSP evaluating Microsoft Intune measured 34 minutes just to initiate a remote wipe during testing. If your treatment assumes an immediate response and your tooling takes half an hour to start, your residual risk is wrong.

The same applies to detection. An IT director managing 600 devices framed it as two questions on a demo call: do we know where this device is, and do we know what we can do to recover it? If the honest answer to either is “it depends,” that’s not a mature control, whatever the policy says. The device loss workflow you can execute under pressure is the one that counts.

Quick win: Pick your three highest-scored risks and test the control you claim to have. Time a remote lock on a test device. Pull an encryption status report. If a step takes longer than your register assumes, update the residual score to match reality.

What goes in the IT risk assessment report

The report is the part everyone postpones and then writes in an afternoon, which is why most of them serve neither reader well.

An IT risk assessment report has five parts: scope and method, the asset inventory it was based on, the prioritized risk register, the treatment decisions with owners and dates, and the residual risk accepted by management. A one-page executive summary sits on top.

Your auditor reads it backward. They want to know what you assessed, how you decided, and whether you can produce evidence. Including the inventory you worked from is what makes the rest defensible: it shows the assessment covered a real population, not a convenient subset. That’s why the reconciliation is worth documenting rather than quietly fixing.

Your management reads the first page and stops. That’s the design constraint, not a criticism. Across demo conversations, the most common thing IT champions ask for is a version of their work they can forward to a manager: what this is, what it costs at our size, and the three things it fixes. Without that layer, the controls you scoped never get funded.

The evidence question is where the two readers converge. A finance organization in Chile had to answer a security questionnaire from its parent company in Belgium covering more than 190 controls. The policy questions were answerable with documents. The operational ones were not: which devices are encrypted right now, which reported this week, how long a remote lock actually takes. Those answers come from systems, and if the report can’t point at where they come from, someone spends two weeks assembling them by hand.

One page of executive summary, a register exported as a table with columns for asset, risk, score, treatment, owner, and due date, and an appendix with the inventory snapshot and its date. Version it and keep the previous cycle; your best evidence next year is showing what changed and why.

The list is the assessment

Frameworks are well documented, scoring matrices are freely available, and report templates are a search away. None of that is where assessments break.

They break at the top, in a spreadsheet that was accurate the day someone built it and has been drifting since. Everything downstream inherits the drift: threat analysis covering assets that no longer exist, scoring on an incomplete population, controls assigned to devices nobody can reach. The work looks complete. It just describes the wrong company.

So before the next cycle, do the unglamorous thing first. Reconcile what you think you have against what’s actually reporting, and write the difference down as a finding instead of cleaning it up quietly. It’s the least sophisticated step in the process and the only one the rest depends on.

Frequently asked questions

How often should you conduct an IT risk assessment?

At minimum once a year, with a full review after any material change: a cloud migration, a merger, a new office, or a significant shift in where people work. Regulated sectors often assess high-risk systems more frequently. Annual cadence is a floor, not a schedule.

What is the IT risk assessment format?

Five parts: scope and methodology, the asset inventory it was based on, the prioritized risk register, treatment decisions with named owners and due dates, and the residual risk formally accepted by management. Most teams add a one-page executive summary and version each cycle for comparison.

What are the five things a risk assessment should include?

An accurate asset inventory, threats and vulnerabilities mapped to those assets, a likelihood and impact score per risk, a documented treatment decision, and an assigned owner with a review date. Missing any one makes the register unusable in practice.

Who should perform an IT risk assessment?

IT or security leads own the process, with input from the business units that own the data at stake. Internal teams handle routine cycles well. External assessors add value when you need independence for a certification, or suspect blind spots your team is too close to see.

What’s the difference between an IT risk assessment and a security audit?

An assessment looks forward: it identifies risks and decides what to do about them. An audit looks backward: it verifies whether you did what you said you would. The assessment defines the controls; the audit checks they’re operating.

See what your inventory looks like when it reports itself. Your risk assessment is only as accurate as the asset list it starts from. Take a look at how a live fleet view compares against the spreadsheet you’re working from today. Get a demo.