IT Risk Assessment Template and Method

An IT risk assessment answers three questions: what do we have, what could go wrong with it, and how much would it matter. You list the assets (systems, data, people, vendors), the threats and vulnerabilities that apply to each, score likelihood and impact, and record the result in a risk register with an owner and a decision for every risk. Done with the right people in the room, a first assessment for a small or mid-sized organization fits in a working week.

The register you produce becomes the document that drives your security budget, your policies, your insurance answers and your HIPAA, SOC 2 or CMMC evidence. This guide gives you the method, the template and the scoring. This is general information, not legal advice.

The IT risk assessment method: five days

The structure follows NIST’s SP 800-30 (prepare, conduct, communicate, maintain) with the steps sized for an organization without a risk team. Each day is a half-day workshop plus desk work.

1. Day 1: scope and inventory. Decide what the assessment covers (the whole company, one product, one site) and who signs off. Build the asset inventory: systems, applications, cloud services, data stores, devices, network equipment, key people and vendors. Record for each asset the owner, the data classification it holds and how critical it is to operations. Finance, operations and HR usually know about systems IT has never seen.
2. Day 2: threats and vulnerabilities. For each asset or group of assets, list what could go wrong (threat events) and the weaknesses that make it possible (vulnerabilities). Use a threat catalog so nothing is forgotten: phishing and account takeover, ransomware, insider error, insider misuse, vendor compromise, lost or stolen device, hardware failure, cloud misconfiguration, software vulnerability, power or connectivity loss, natural hazard, regulatory change. Pair each with evidence: no MFA, backups untested, end-of-support software, single administrator, no contract with the vendor.
3. Day 3: scoring. Score likelihood and impact for each risk using the scales in the next section, calculate the risk rating, and sort. Do this in a group so the scores are challenged. The point is relative ranking, not precision.
4. Day 4: treatment. For each risk above your acceptance line, decide: mitigate (add a control), transfer (insurance or a vendor contract), avoid (stop the activity) or accept (document why). Assign an owner and a target date for every mitigation.
5. Day 5: report and sign-off. Write a short report: scope, method, the top risks in plain language, the treatment plan, the accepted risks and the review date. Leadership signs it. That signature is what turns a spreadsheet into a management decision, and it is what auditors and regulators look for.

Then maintain it: review quarterly, update after any incident, major change or new vendor, and repeat the full exercise at least yearly.

IT risk assessment template

Two sheets are enough: the asset inventory and the risk register. Use a spreadsheet or a ticketing tool; the columns are what matter.

Asset inventory columns

Asset ID | Asset name | Type (system, data, device, vendor, people) | Owner | Location or hosting
Data classification (public, internal, confidential, regulated) | Criticality (1 to 5)
Users or dependencies | Notes (version, support status, contract end date)

Risk register columns

Risk ID | Asset(s) | Threat event | Vulnerability (why it is possible) | Existing controls
Likelihood (1 to 5) | Impact (1 to 5) | Risk rating (L x I) | Rating band (Low, Medium, High, Critical)
Treatment (Mitigate, Transfer, Avoid, Accept) | Planned control | Owner | Target date
Residual likelihood | Residual impact | Residual rating | Status | Review date | Approved by

Sample rows

Risk ID	Asset	Threat event	Vulnerability	L	I	Rating	Treatment	Planned control	Owner
R-01	Email (cloud tenant)	Account takeover via phishing	MFA not enforced for all users	4	4	16 (High)	Mitigate	Enforce MFA tenant-wide; block legacy authentication	IT manager
R-02	File server	Ransomware encrypts shared drives	Backups online only, never restored	3	5	15 (High)	Mitigate	Immutable offsite copy; quarterly restore test	IT manager
R-03	Accounting system	Fraudulent payment via changed supplier bank details	No verification procedure	3	4	12 (Medium)	Mitigate	Callback verification rule; dual approval over a threshold	Finance lead
R-04	Line-of-business application	Vendor ceases support; vulnerability unpatched	Application on end-of-support platform	2	4	8 (Medium)	Transfer then mitigate	Contract review; plan migration within the year	Operations lead
R-05	Office network	Extended power outage	Single site, no failover	2	2	4 (Low)	Accept	Documented; staff can work remotely	Owner

Keep the “existing controls” column honest. “We have antivirus” is a control only if it is on every device and someone reads the alerts. If your organization handles health data, the same register, with every system that holds ePHI in scope, is the core of the HIPAA security risk analysis.

Scoring likelihood and impact

Use five-point scales with written definitions, so two people scoring the same risk get the same answer. Adapt the impact wording to your organization: a clinic defines impact in terms of patient care and regulatory exposure, a software company in terms of customer data and service availability.

Score	Likelihood (in the next year)	Impact
1	Rare: would require unusual circumstances	Negligible: absorbed in normal operations, no external notice
2	Unlikely: could happen but not expected	Minor: short disruption, small cost, handled internally
3	Possible: has happened to similar organizations	Moderate: a day or more of disruption, noticeable cost, some customers affected
4	Likely: expected to occur at some point	Major: extended outage, regulatory notification, significant loss, customer departures
5	Almost certain: already occurring or attempted regularly	Severe: threatens the organization’s survival, major legal or regulatory action, patient or public harm

Multiply likelihood by impact to get a rating from 1 to 25, then set bands: 1 to 4 Low, 5 to 9 Medium, 10 to 16 High, 17 to 25 Critical. Draw the acceptance line where leadership is comfortable; many organizations accept Low risks by default, require a documented decision for Medium, and require a treatment plan for High and Critical.

Two refinements when you are ready for them. Score impact separately for confidentiality, integrity and availability and take the highest, which stops availability risks from drowning out data-exposure risks. And when a decision needs a money figure (insurance limits, a large control investment), a quantitative method such as FAIR estimates loss ranges for the handful of risks that justify the effort. For a first assessment, the qualitative scale is enough.

Treatment: what to do with each risk

A cybersecurity risk assessment that ends at the scoring step is a worry list. Treatment is where it becomes it risk management.

• Mitigate. Add or improve a control until the residual rating is below the acceptance line. Prefer the smallest control that does the job and the controls that reduce several risks at once: MFA, tested backups, patching and least privilege each appear in half the register. The fifteen small-business controls are the usual first candidates.
• Transfer. Move part of the financial impact to an insurer or a vendor through contract terms. Transfer never removes the operational impact or your legal obligations, so it usually pairs with mitigation.
• Avoid. Stop doing the thing: decommission the legacy server, stop collecting data you do not need, end the vendor relationship.
• Accept. Decide, in writing and at the right level of authority, that the risk is tolerable. Acceptance is legitimate; silent acceptance is not.

Record the residual score after treatment, so the register shows both where you were and where you expect to be. Report upward in one page: the top risks, what is being done, what has been accepted and what needs a decision or money. Mapping the register to the Identify and Govern functions of the NIST Cybersecurity Framework lets the same document answer customer questionnaires and insurance forms.

Where PS3G fits

PS3G runs IT security assessments and risk assessments for organizations of every size, from a founder who needs a first register for a customer review to a multi-site company preparing for an audit. Our cybersecurity consulting team facilitates the workshops, brings the threat catalog and the scoring scales, performs the technical review (configuration, vulnerability scanning, access) that gives the scores evidence, writes the report leadership signs, and then helps implement the treatment plan. The register stays yours, in your tools, maintained on a cycle you can keep.

Related reading

• Cybersecurity for Small Business: The 15 Controls That Matter Most
• NIST Cybersecurity Framework Explained for Smaller Companies
• HIPAA Compliance Checklist for Small Practices and Health-Tech Vendors
• Cybersecurity consulting and information security services

Frequently asked questions

What is the difference between an IT risk assessment and an IT security assessment?

A risk assessment is the business exercise: assets, threats, likelihood, impact and decisions, owned by management. A security assessment is the technical review that feeds it: configuration checks, vulnerability scans, access reviews and policy review. You need both. The security assessment tells you which vulnerabilities are real; the risk assessment tells you which ones matter enough to fix first.

How often should an IT risk assessment be done?

Review the register quarterly, update it after any incident, significant change or new vendor, and repeat the full assessment at least annually. Regulated organizations should check their specific obligations; HIPAA, for example, requires the risk analysis to be kept current and reviewed after changes, and SOC 2 auditors expect an annual assessment with evidence of management review.

Who should be involved in the assessment?

Whoever owns the assets and whoever will own the risks: the IT lead, the operations or finance lead, a representative of any team with its own systems, and a decision-maker who can accept risk and approve spending. A ten-person company can do it with two people and the owner. Larger organizations add department representatives, but keep the core group small enough to finish in a week.

Do I need special software for a risk register?

No. A spreadsheet with the columns in this guide works for most organizations and is what many auditors see. Move to a governance, risk and compliance tool when you have many registers, many owners, or need workflow and audit trails around approvals. The discipline of reviewing the register on a schedule matters far more than the tool that holds it.

Is qualitative scoring good enough?

For prioritizing and for most audits, yes. Five-point scales with written definitions, scored by a group, give a consistent ranking and a defensible record. Quantitative methods that estimate loss in money terms are valuable for a few large decisions, such as insurance limits or a major infrastructure investment, and are best applied to the top handful of risks after the qualitative pass has identified them.