TL;DR:
An IT risk assessment is the structured process of identifying the risks to your IT systems and data, analysing how likely each one is and how much damage it would do, then deciding how to treat it.
It turns a vague sense of exposure into a ranked, owned list, which is why DORA, NIS2 and ISO 27001 build their requirements around it.
This guide covers what the assessment produces, when to run one, the process in order, the two methods, how it maps to the frameworks in scope, what IT risk management software changes, and where assessments go wrong.
What an IT risk assessment produces
Every IT risk assessment should end with a defined set of records rather than a narrative report. The outputs are:
- An inventory of systems, data and the services they depend on;
- A view of which of those are critical to the business;
- Identified threats and vulnerabilities against each critical asset;
- A likelihood and impact rating for every risk;
- A treatment decision for each: reduce, accept, transfer or avoid;
- A risk register recording all of it, with owners and dates.
Those records are also most of the evidence auditors and frameworks such as ISO 27001, SOC 2, PCI DSS and DORA expect to see, and they feed the contingency and continuity planning that operational resilience requirements are built on.
IT risk, ICT risk, and enterprise risk: what the assessment actually covers
Why does the same exercise carry three different names? Because three different audiences ask for it.
An IT risk assessment covers risks to information systems and the data they hold: confidentiality, integrity, availability, and the technology the business runs on. ICT risk is the term DORA and the EU financial supervisors use for the same scope, framed around operational resilience rather than information security.
A payments firm running an ICT risk assessment and a SaaS company running an IT risk assessment for ISO 27001 are doing substantially the same work in different vocabulary. Enterprise risk sits above both, covering financial, legal, strategic and reputational exposure across the whole business. An IT risk assessment feeds that picture without replacing it.
The practical consequence for anyone in DORA or NIS2 scope: use the regulator’s vocabulary in regulator-facing documents, but run IT and ICT risk assessment as one process.
When to run an IT risk assessment
Most teams run the assessment once a year because a framework asks for it. The triggers that actually change the risk picture are broader:
- On a defined cycle, commonly annual, more often in higher-risk environments;
- When a new system, or a material change to an existing one, goes live;
- When a new vendor or critical third party is onboarded;
- When a new framework or regulation comes into scope;
- After an incident or a near miss.
Each of those is a moment the risk picture changed.
An assessment that only refreshes on the anniversary of the last one describes the previous version of the business.
DORA is explicit about this for financial entities: asset classification and risk scenarios are reviewed at least yearly, and legacy systems get a specific assessment before and after anything is connected to them.
The IT risk assessment process, step by step
The wording differs by source. ISO/IEC 27005, NIST and DORA describe the sequence in slightly different terms, and the labels matter far less than the order.
Assets first, business impact second, risks third, controls last, which is the reverse of where most teams are tempted to start.
Step 1: inventory your assets
You cannot assess risk to something you have not written down. The inventory covers systems, applications, data stores, infrastructure, and the third-party services those depend on, including the ones procured outside IT.
Take a payments business: the list should include every system that touches customer payment data, the databases behind them, and the vendors operating any part of that path. Miss the reconciliation tool a finance team bought on a company card and no amount of rigour downstream will surface the risk attached to it.
An incomplete inventory quietly caps the accuracy of everything that follows.
Step 2: run a business impact analysis
Before rating a single threat, decide which of those assets matter. A business impact analysis does that: it identifies the critical business functions and the assets, vendors and processes inside them, so assessment effort lands where failure would actually hurt. A payment authorisation system outranks the internal wiki. Both sit on the asset register; only one stops the business.
Skip the business impact analysis and every risk looks equally urgent, which means the assessment ends up prioritised by whichever asset the assessor thought about hardest. DORA is direct about it, requiring financial entities to assess the impact of severe business disruption using quantitative and qualitative criteria, weighing the criticality of business functions, third-party dependencies and information assets.
Step 3: identify threats and vulnerabilities
For each critical asset, two questions: what could go wrong, and what weakness would let it happen. Threats and vulnerabilities are assessed as pairs, and the pairing is what makes a risk concrete enough to rate.
The common sources are technical (unpatched systems, weak access control, missing encryption), human (misconfiguration, phishing, privileged access that was never revoked), third-party (a critical vendor outage or a compromise in their environment), and environmental (power, facilities, region-level cloud failure).
An internet-facing server running an unpatched component, paired with a known exploit in circulation, is a risk you can describe in one line and rate in the next. An entry that just says “cyber attack” cannot be rated at all.
Step 4: analyse and rate each risk
Each risk gets a rating from two factors: how likely it is and how bad the impact would be.
A risk matrix is the standard tool, scoring likelihood and impact on a scale (five by five is common) and multiplying them, so that a risk scoring 16 or above sits in the red band demanding treatment and a named owner.
Ratings can be descriptive (high, medium, low) or quantitative, which the next section covers.
You choose that threshold; no standard sets it for you. ISO 27001 requires you to define risk acceptance criteria and apply them consistently, and says nothing about where red starts. A low-likelihood, high-impact scenario, total loss of a customer database, will usually score into treatment anyway.
Step 5: decide how to treat each risk
Four options, and only four:
– Reduce the risk with a control;
– Accept it, if it falls inside tolerance;
– Transfer it, through insurance or a contractual provision;
– Avoid it, by stopping the activity that creates it.
The label is the easy part. A treatment decision without an owner and a date is a note, and it will still be a note at the next audit. Accepting a risk is legitimate, but only when someone with the authority to carry the consequence has signed it off, which is what an auditor will ask to see.
Controls enter here, at the end, sized to the exposure that was measured rather than lifted from a checklist. A high-rated privileged access risk might be treated with mandatory MFA and quarterly access reviews, owned by the head of IT, reviewed in ninety days.
Qualitative vs quantitative IT risk assessment
Which method should you use? Both, at different depths.
Qualitative assessment scores likelihood and impact in descriptive bands and plots them on a matrix. It is quick, needs no historical loss data, and is good enough for a first register. The weakness is subjectivity: two assessors can rate the same risk differently and the scale gives you no way to settle it.
Quantitative assessment puts numbers on both factors and expresses exposure in money. The FAIR model (Factor Analysis of Information Risk) is the best-known method for quantifying cybersecurity and operational risk this way, breaking loss event frequency and loss magnitude into components you can estimate.
External benchmarks give you an anchor: IBM’s Cost of a Data Breach Report 2026 puts the global average at USD 4.99 million, up 12 per cent on the prior year. Quantification sharpens prioritisation and changes the board conversation, and it costs considerably more effort to produce.
Most teams start qualitative across the estate, then add quantitative depth to the few risks where a number would change a decision.
| Qualitative | Quantitative | |
|---|---|---|
| Effort | Low: workshops and a matrix | High: loss data, modelling, assumptions you can defend |
| Output | Descriptive bands and a ranked matrix | Monetary exposure, usually as a range |
| Best for | First assessments, broad coverage, smaller teams | Critical risks, budget cases, board reporting |
| Main weakness | Subjective and hard to challenge | Data-hungry, and false precision when inputs are weak |
How an IT risk assessment maps to DORA, NIS2 and ISO 27001
One assessment, several sets of requirements. The frameworks use different vocabulary and different scopes, and all of them require you to identify, rate and treat risk, so the underlying work is reusable.
DORA, a regulation applying directly across the EU, is the most specific. Regulation (EU) 2022/2554 requires financial entities to maintain a documented ICT risk management framework (Article 6) and, within it, to identify, classify and document all ICT-supported business functions, the information and ICT assets behind them, and their dependencies (Article 8). Sources of ICT risk are identified on a continuous basis, with risk scenarios reviewed at least yearly. The assets, impact, risk and treatment sequence is what DORA’s ICT risk management framework asks for. A free DORA self-assessment is a quick way to see where you currently stand.
ISO/IEC 27001:2022 is a certifiable standard. Clause 6.1.2 requires a documented information security risk assessment with defined acceptance criteria and repeatable results, and Clause 6.1.3 requires treatment, producing the Statement of Applicability. ISO/IEC 27005 holds the process guidance the requirements clause leaves out, and given how heavily the two regimes overlap, mapping DORA to ISO 27001 removes most of the duplicated effort.
NIS2 is a directive, transposed into national law rather than applied directly. Article 21 of Directive (EU) 2022/2555 requires proportionate technical, operational and organisational measures on an all-hazards basis, with risk analysis named first among them. SOC 2 is an attestation and PCI DSS a contractual industry standard; both expect a documented risk assessment and neither prescribes a method. The same risk work underpins compliance with legal requirements such as GDPR and, for organisations handling US health data, HIPAA, where security measures proportionate to assessed risk are what keeps a regulator from issuing a penalty.
One well-run assessment can answer an ISO 27001 clause, a SOC 2 criterion and a DORA requirement at once, provided it is documented in a form each will accept.
Turn the assessment into a living risk register
The assessment produces a document. The document then has to become something that keeps working.
A risk register is where that happens: each risk recorded with its rating, the control that addresses it, the owner accountable for it, and the date it was last reviewed. It changes as the business changes. A new vendor, a cloud migration, a new product line, a new regulation in scope, each one adds or retires entries. A register rebuilt from scratch the month before an audit describes the company as it was a year ago, carrying risks against systems that have since been decommissioned while nothing has been assessed for the systems that replaced them.
Copla keeps the register live as part of continuous compliance work, linking risks to controls and owners and capturing evidence as tasks are completed rather than gathering it retrospectively. The register stays current because updating it is the same work the team is already doing.
A current register answers a question an annual one cannot: of everything recorded in it, what is still true?
IT risk assessment tools and software
Teams run IT risk assessments somewhere on a spectrum. At one end, spreadsheets and framework templates: workable, cheap, and completely dependent on the discipline of whoever maintains them. They fail in predictable ways, with version conflicts and no record of who changed a rating or why.
At the other end, dedicated risk and GRC platforms: asset and vendor registers, configurable matrices, treatment tracking with owners and deadlines, evidence linked to controls, and reuse of one assessment across several frameworks. What usually justifies the spend is the audit trail and the cross-framework reuse rather than the scoring itself.
Neither spreadsheets nor dedicated platforms decide which risks are acceptable. Software can route, remind, calculate and evidence. Tolerance is set by people who can be held to it.
Common IT risk assessment mistakes and how to avoid them
Five recur often enough to name.
Starting from a control checklist.
Teams work through Annex A or the DORA articles and reverse-engineer risks to justify controls they had already decided on. Effort then follows the checklist instead of the exposure. Fix the sequence: assets, impact, risk, then controls.
Assessing everything to the same depth.
A register where every entry received equal attention is a register where the critical entries were under-examined. Size the depth to criticality.
Letting it go stale.
An assessment signed off in March and untouched until the following March is a historical record by the summer. Tie reviews to the triggers listed above.
Risks with no owner or date.
A risk nobody owns will still be open at the next review. Every entry needs a name and a review date.
Treating acceptance as a shrug.
“Accept” from someone without the authority to accept it will not survive an auditor’s question. Get it signed.
If several of these look familiar, a gap analysis is the usual place to start: establish what is missing against the framework you answer to, assign owners to the gaps, and work the list.
Who owns the IT risk assessment, and where judgment comes in
Ownership is distributed. Asset and system owners supply the detail, since they are the only people who know what a system actually does. IT and security run the technical analysis. A CISO or head of compliance owns the programme and signs off the output. Auditors test whether it holds up.
What software cannot take on is the judgment. Is this rating right. Is this treatment adequate. Is this acceptance defensible to a supervisor. Does this exception need escalating.
A platform can draft, flag, route and remind; an accountable person confirms.
Smaller teams often bring that judgment in on a fractional basis rather than hiring a consultant per assessment, which is the model behind Copla’s CISO support. Responsibility for compliance stays with the organisation either way.
Copla runs the sequence in this guide, assets to business impact analysis to risk register, as continuous guided work rather than an annual project. To see how that looks against your own framework and vendor list, book a free consultation.
FAQ
-
What is the IT risk assessment?
-
How do you perform an IT risk assessment?
-
What are the 5 things a risk assessment should include?
-
How long does an IT risk assessment take?
-
What is the difference between an IT risk assessment and a business impact analysis?
-
What is the difference between an IT risk assessment and a vulnerability scan or penetration test?
-
Which methodology or standard should an IT risk assessment follow?
-
What is the IT risk assessment format?
-
Do IT risk assessments cover cloud and third-party systems?
-
What counts as an acceptable level of risk?
