A cybersecurity risk assessment connects systems and weaknesses to possible business harm. It should identify important assets, existing controls, plausible failure scenarios and prioritized treatment decisions. Zoha scopes software and business-system reviews so the output is an owned risk register and action plan, with assumptions and limitations visible to management.
Updated
On this page
Begin with the business service, then map the systems
Ask what the business must protect: the ability to take orders, access operational records, communicate with customers or keep restricted information confidential. Identify the applications, accounts, data stores and suppliers supporting that service. This is more useful than rating every device as equally important.
Include the people who understand the process as well as those who maintain the software. A developer can explain a permission boundary; the business owner can explain what an unauthorized change would cost operationally. Neither view alone produces a complete priority.
Use a clear and proportionate assessment method
We define the asset set, information sources and risk criteria before the review. Existing reports, access records, architecture notes and conversations with owners can provide evidence. Focused technical checks may be added where authorized, but a risk assessment should not silently expand into penetration testing.
Describe likelihood and impact using agreed definitions. If a rating depends on an assumption, state it. Numerical scores can help organize a register, but they should not imply precision the evidence cannot support. The purpose is a defensible decision about action, not an impressive-looking score.
A worked example of a useful risk register
| Hypothetical scenario | Evidence to review | Possible treatment and owner |
|---|---|---|
| A former supplier retains application administration access | Account list, ownership and offboarding records | Application owner reviews access and removes permissions no longer required. |
| A critical record cannot be restored | Backup configuration and restore evidence | Operations owner agrees recovery needs and verifies a restore. |
| Users can make sensitive changes without an appropriate role | Application permissions and authorized role tests | Development owner corrects authorization and arranges verification. |
| One person holds the only recovery details | Account ownership and documented recovery process | Business owner establishes controlled recovery access. |
The final register should also record the affected service, current controls, priority, target decision and status. Keep sensitive evidence in an appropriately restricted location rather than pasting passwords or customer records into the register.
Assign treatment decisions to people who can act
- Reduce a risk with a specified technical or process change.
- Avoid an activity when its exposure is unacceptable for the business.
- Address supplier responsibilities through the appropriate contract and operating arrangement.
- Accept a residual risk only through the person authorized to make that decision.
- Set a review point and evidence requirement for every agreed action.
A supplier can recommend treatment but should not quietly accept business risk on the customer's behalf. Where several fixes depend on the same account or application change, sequence them together. That makes the plan easier to implement and reduces repeated disruption.
Leave management with a usable record
Expect an agreed scope, evidence summary, risk register and prioritized treatment plan. The report should identify unreviewed assets, missing information and questions requiring legal or specialist advice. Separate immediate technical changes from work that needs a business or supplier decision.
NIST's Cybersecurity Framework can help organize the discussion across governance, protection, detection, response and recovery. It does not replace an assessment of your actual environment. We can scope implementation of agreed software changes and a follow-up review so the register reflects progress rather than becoming a static document.