Overview
Risk Register
Field Descriptions
Score Definition
Risk Assessment Matrix
Sheet 1: Risk Register
| Risk Assessment Template | |||||||||||||||||||||
| Risk Assessment | Risk Ranking | Risk Treatment | |||||||||||||||||||
| ID | Risk Scenario | Risk Type (CIA) | Nonconformity? | Impacted Asset | Existing Controls (if applicable) |
Vulnerabilities | Impact | Likelihood | Risk Score | Risk Treatment | Risk Treatment Detail | Annex A Ref. (optional) | Residual Impact | Residual Likelihood | Residual Risk Score | Risk Owner | Risk Owner Approval | Implementer (optional) | Action Tracking (optional) | Action Due Date | Risk Treatment Status |
| 1 | Example: Background checks are not completed for new hires at time of onboarding | Confidentiality | No | People | Background checks are required by the HR Security Policy which is current and accepted by employees | No clear control owner | 1 | 3 | 3 | Mitigate | 1. Assign an risk owner to be responsible for making sure BG checks are completed on time for all employees 2. Develop tracking system and reportable key results indicators (KRIs) around this control 3. Review compliance and KRIs and present issues at quarterly meetings |
A7 – HR Security | 1 | 1 | 1 | Head of Engineering | 1 | Office Manager | 1. Quarterly Security Team Meeting will review implementation status
2. ServiceDesk Ticket #045439 |
7/14/21 | In Progress |
| 2 | Example: Windows webservers do not have antivirus |
Confidentiality | No | Technology | 1. NACLs in place 2. WAF in place |
Vulnerable, public-facing windows host with no AV. | 2 | 2 | 4 | Mitigate | Install antivirus on webservers | A12 – Operations Security | 2 | 1 | 2 | Head of Engineering | 1 | Sys Admin | JIRA #125546 | 7/1/21 | Not Started |
| 3 | Example: Manual customer data deletion process is not reliably meeting SLAs | Confidentiality | No | Data | 1. Manual deletion process is defined | 1. Manual process lacks owner 2. SLAs not consistently met |
1 | 1 | 1 | Mitigate | 1. Automate customer data deletion 2. Implement quaterly review porocess to monitor deletion compliance with contract SLAs |
A18 – Compliance | 1 | 1 | 1 | Head of Engineering | 1 | Customer Success & DevOps | 1. JIRA #125577 2. SerivceDesk #033999 3. Quarterly Security Team Meeting will review implementation status |
9/1/21 | In Progress |
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
| 0 | 0 | 0 | |||||||||||||||||||
Sheet 2: Field Descriptions
| ID | Risk Scenario | Risk Type | Non-conformity? | Impacted Asset | Existing Controls (if applicable) | Vulnerabilities (optional) | Impact | Likelihood | Risk Score | Risk Treatment Option (Accept, Transfer, Mitigate, Avoid) | Risk Treatment Detail | Annex A Ref. (Optional) | Residual Impact | Residual Likelihood | Residual Risk Score | Risk Owner | Risk Owner Approval | Implementer (Optional) | Action Tracking (Optional) | Action Due Date (Optional) | Risk Treatment Status |
| This is simply a reference number, it allows you to track or refer to a specific risk in this or other documents. | This describes an actual or potential risk to your organization’s people, processes, technology, data, and facilities. Document actual issues (e.g. you found unpatched systems as the result of a vulnerability scan) or likely scenarios based on your specific environment or a potential vulnerability (e.g. employee could expose customer data because laptops are not encrypted). | Indicate the closest match for the type of risk documented: – Risk to data stores, customer/sensitive information, etc. (Confidentiality) – Risk to accuracy or integrity of system settings and/or data (integrity) – Risk to normal service operations and critical system functionality (Availability) |
If the risk is the result of an Internal or External audit (generally noted by your Auditor in the report) indicate “Yes”. If the risk was identified through a source other than an Auditor report indicate “No”. | Chose the most likely category that would be impacted by the identified risk (e.g. lack of cameras at a facility would be classified as “Physical” , whereas a lack of a data retention and disposal process would be classified as “Data”. | This is intended to help your organization document other controls that may mitigate or negate the identified risk. For instance, a risk indicating that weak passwords are used may be mitigated by requiring the use of multifactor authentication. This field can be left blank if you have no existing controls that would apply here. | This is an optional field that allows you to add a bit more background around the reason a risk was included in this register. Though the terms “risk”, “threat”, and “vulnerability” are often used interchangeably, a “vulnerability” is an overall weakness in your security program that could allow someone/something (the “threat”) to obtain, damage, or destroy your organization’s assets. If you have existing controls, a vulnerability may be issues with that control that mean it does not appropraitely treat the risk identified.
For example: |
This number represents how negatively the exploitation of this risk/vulnerability would impact your organization’s ability to continue providing services, make money, or protect critical people/processes/technology/facilities/data.
A “1” denotes the lowest impact, and a “3” represents a significant impact. |
This number represents how likely it is that an intentional or accidental incident will take place based on this risk/vulnerability.
A “1” means something is unlikely to happen, where a “3” indicates a high likelihood. |
This is automatically calculated by multiplying impact by likelihood. | This field indicates what your leadership team wants to do to address an identified risk, and is similar to a cost/benefit analysis. Please note: not all risks need to be addressed immediately (or at all). Your Risk Treatment decision will depend on multiple factors, such as your organization’s risk tolerance and the value of the asset that the risk is associated with. The options are: – Accept: decide to live with the risk; this may be because it is highly unlikely, has a low financial or operational impact, or the cost and effort to treat the risk far exceeds the value of the asset – Transfer: make the risk “someone else’s problem”, e.g. through Cyberinsurance or outsourcing – Mitigate: put controls in place that will reduce the likelihood/impact of the risk – Avoid: fix the risk and underlying vulnerabilities in order to remove from your risk environment |
This field indicates what steps your organization will perform to “Treat” (fix or mitigate) the identified risk. For instance, a Risk Treatment description for lack of malware controls may be “Install antivirus software on all servers and endpoints”. | If you are referencing an ISO 27k Annex A control indicate the closest match to the control area here. | This field is intended to calculate the risk that will remain after your organization has applied the Risk Treatment. Again, the goal may not be to get the risk to “zero”; your approach will be based on your organization’s risk tolerance, industry and regulatory requirements, business objectives, etc. | This field is intended to calculate the likelihood that a risk will be exploited or impact operations after your organization has applied your Risk Treatment. | This is automatically calculated by multiplying Residual Impact by Residual Likelihood. | This field indicates who owns and tracks the remediation of the identified risk. This could be a team/department (Human Resources) or an individual (Sarah in IT Operations). | This field indicates whether the identified Risk Owner has reviewed the risk and approved the Risk Treatment plan. | Indicate who is responsible for mitigating or eliminating the risk based on the defined Risk Treatment plan. | This field is for tracking how your organization is tracking the Risk Treatment. This could be through reoccurring Risk Management Team meeting, a tracking ticket, etc. | This field is for tracking the timeline for next actions or execution of Risk Treatment plan. | Indicate the current status of Risk Treatment. |
Sheet 3: Score Definition
| Impact & likelihood scores | Risk score and rating | Risk treatment options | ISO Annex A reference | Risk Source | Risk Type | Non-conformity? | Asset | Risk Status | |||||||||
| Low | 1 | 1-2 (Low) | Accept | A5 – Information Security Policies | Internal Audit | Confidentiality | Yes | Data | Not Started | ||||||||
| Moderate | 2 | 3-6 (Moderate Risk) | Transfer | A6 – Organization of Information Security | External Audit | Integrity | No | People | In Progress | ||||||||
| High | 3 | 9 (High Risk) | Mitigate | A7 – HR Security | Risk Assessment | Availability | Major | Process | Resolved | ||||||||
| Avoid | A8 – Asset Management | Technical Test | Minor | Technology | Cancelled | ||||||||||||
| A9 – Access Control | Incident | Physical | Postponed | ||||||||||||||
| A10 – Cryptography | Tabletop Test | ||||||||||||||||
| A11 – Physical Security | Reported (Internal) | ||||||||||||||||
| A12 – Operations Security | Reported (External) | ||||||||||||||||
| A13 – Communications Security | Monitoring & Alerts | ||||||||||||||||
| A14 – System Acquisition, Development & Maintenance | Other | ||||||||||||||||
| A15 – Supplier (Third Party) Relationships | |||||||||||||||||
| A16 – InfoSec Incident Management | |||||||||||||||||
| A17 – Business Continuity Management | |||||||||||||||||
| A18 – Compliance | |||||||||||||||||
Sheet 4: Risk Assessment Matrix
| Appendix A: Risk Assessment Matrix and Description Key | ||||
| Device trader | RISK = LIKELIHOOD * IMPACT |
LIKELIHOOD | ||
| Very likely: 3 |
Somewhat likely: 2 |
Not likely: 1 |
||
| IMPACT | Very impactful: 3 | 1 | 6 | 3 |
| Somewhat impactful: 2 | 6 | 4 | 2 | |
| Not impactful: 1 | 3 | 2 | 1 | |
| RISK LEVEL | RISK DESCRIPTION | |||
| Low (1–2) | A threat event could be expected to have a limited adverse effect on organizational operations, mission capabilities, assets, individuals, customers or other organizations. | |||
| Moderate (3–6) | A threat event could be expected to have a serious adverse effect on organizational operations, mission capabilities, assets, individuals, customers or other organizations | |||
| High (7–9) | A threat event could be expected to have a severe adverse effect on organizational operations, mission capabilities, assets, individuals, customers or other organizations. | |||
| IMPACT LEVEL | IMPACT DESCRIPTION | |||
| Not impactful (1) | A threat event could be expected to have a limited adverse effect, meaning: degradation of mission capability yet primary functions can still be performed; minor damage; minor financial loss; or range of effects is limited to some cyber resources but no critical resources. | |||
| Somewhat impactful (2) | A threat event could be expected to have a serious adverse effect, meaning: significant degradation of mission capability yet primary functions can still be performed at a reduced capacity; minor damage; minor financial loss; or range of effects is significant to some cyber resources and some critical resources. | |||
| Very impactful (3) | A threat event could be expected to have a severe or catastrophic adverse effect, meaning: severe degradation or loss of mission capability and one or more primary functions cannot be performed; major damage; major financial loss; or range of effects is extensive to most cyber resources and most critical resources. | |||
| LIKELIHOOD LEVEL | LIKELIHOOD DESCRIPTION | |||
| Not likely (1) | Adversary is unlikely to initiate a threat event; non-adversarial threat event (e.g., nature, error, accident) is unlikely to occur; or threat is unlikely to have adverse impacts. | |||
| Somewhat likely (2) | Adversary is somewhat unlikely to initiate a threat event; non-adversarial threat event (e.g., nature, error, accident) is somewhat unlikely to occur; or threat is somewhat unlikely to have adverse impacts. | |||
| Very likely (3) | Adversary is highly likely to initiate a threat event; non-adversarial threat event (e.g., nature, error, accident) is highly likely to occur; or threat is highly likely to have adverse impacts. | |||
