Risk assessment 101: Working backwards from the controls
Performing an information security risk assessment in order to meet the requirements of ISO 27001, SOC 2, PCI DSS, or HIPAA can feel a bit daunting at first. The truth is there are a number of different approaches and methodologies that can work. In this article, I’m going to provide you with a simple and practical example of how you can start with a controls framework, like the ISO 27001 Annex A, and work backwards.
Start with any control. In this example let’s use the first control from the ISO 27001 Annex A:
Section A.5 Information Security Policies includes an information security objective, which is: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
The first control is A.5.1.1 Policies for Information Security: A set of policies for information security shall be defined, approved by management, published and communicated to employees and relevant external parties.
In summary, this control activity indicates that companies should communicate approved policies to personnel so that those personnel know how to perform their job roles in accordance with the direction and rules set by management.
Facing vulnerabilities in the org
The first step after we read and understand the control is to assess how well our organization has implemented it. To the extent that we haven’t implemented the control, those gaps will be listed on our Risk Assessment document as Vulnerabilities.
Policy vulnerabilities could include things like the following:
- We don’t have any security policies
- Policies are old and out of date
- Policies are inaccurate and/or contradictory
- Policies have not been reviewed and approved by management
- Policies haven’t been published or communicated to personnel
- Policies haven’t been acknowledged or accepted by personnel
- Personnel can’t find or access policies when needed
- Policies are too long, too technical, or generally not understandable by the user
What’s the risk then? The risks of not effectively implementing policies could include:
- Personnel don’t understand the rules or management’s direction
- Personnel take actions that are not consistent with the will of management
- Personnel perform actions based on incorrect or out-of-date procedures
- Management lacks a mechanism to direct the organization’s behavior
The next question to ask is: If we have issues or weaknesses with policies, do we have any other controls that could mitigate those potential risks? We can list those as Existing Controls. For example:
- All employees perform security awareness training
- Employees receive targeted training relevant to their role
- Managers meet with direct reports weekly to review their work
- Managers are responsible to mentor and provide ad hoc guidance
- Logging and alerting systems detect and alert on technical misconfigurations or vulnerabilities
After considering the potential risks along with the vulnerabilities and existing controls, we will document a Risk Scenario which could be the most important potential risk or a combination of possible risks. An example risk scenario could be as follows:
- Users perform insecure actions because they are not aware of company security policies
Identifying risk scenarios
Having identified the Risk Scenario we now need to assess the likelihood and impact of the risk materializing which will be combined to give the overall Risk Score. Typically, the likelihood, impact, and overall risk are ranked on a scale of 1-3 or 1-5, which represents something like low, medium, and high.
For this example, we’ll say the likelihood of the risk materializing is a medium likelihood with a score of two (2). The rationale is that while we do lack clear policy direction, a mitigating factor is that employees can solicit management for direction and they do receive basic security training.
Let’s say the impact is also medium or two (2). The rationale is that we expect employees to have enough security awareness and competence to ask for help before taking an insecure action, but the possibility exists that that won’t always happen. An employee could make a serious mistake, like misconfiguring a publicly accessible datastore to allow unauthorized access to sensitive data.
Using a simple multiplication methodology, the overall risk score in this case would be four (4), which would represent a medium risk overall according to our method.
Now a common mistake is to get hung up on the scoring for likelihood, impact, and overall risk. Don’t worry about that too much. It’s a subjective determination, just do your best. The most important thing is to identify and document the risk scenario. You can always adjust the scoring later based on a reconsideration or new inputs.
The next step is to determine the Risk Treatment. The typical options are: Accept, Remediate, Transfer, or Avoid. In our case we’ll mitigate the risk through some planned actions which we’ll call our Risk Treatment Plan.
The last major step now is to document our Risk Treatment Plan, in ISO terms, or simply, the tasks that we will take to mitigate the risk. Our risk treatment plan will be as follows:
- Create, review, and/or update all relevant information security policies
- Obtain management approval for all final policies
- Publish and communicate policies to relevant users
- Obtain user acknowledgement or acceptance of all relevant policies
- Implement a process for new hires to acknowledge and accept policies at time of hire
- Implement a policy to review, update, approve, and communicate policies at least annually
In order for this risk assessment to meet ISO 27001 requirements we need to assign a Risk Owner to each risk and obtain their approval of the risk treatment plan.
That’s basically it. You can get a lot more fancy with information like threats, mappings to specific assets or control frameworks, but we’ve covered the essential elements.
Working backwards from control sets such as the ISO 27001 Annex A is a great approach for organizations that are relatively new to formal risk assessment. I recently worked through the Department of Health and Human Services’ HIPAA Risk Security Risk Assessment (SRA) Tool, and it took a very similar approach, based on the HIPAA Security Rule control requirements.
There are various methods for assessing risk, this is a simple and straightforward approach to help you get started.
About the author: Matt Cooper is Principal, Cybersecurity & Data Privacy on Vanta’s sales team. Matt has been with Vanta since February of 2021.
PCI Compliance Selection Guide
Determine Your PCI Compliance Level
If your organization processes, stores, or transmits cardholder data, you must comply with the Payment Card Industry Data Security Standard (PCI DSS), a global mandate created by major credit card companies. Compliance is mandatory for any business that accepts credit card payments.
When establishing strategies for implementing and maintaining PCI compliance, your organization needs to understand what constitutes a Merchant or Service Provider, and whether a Self Assessment Questionnaire (SAQ) or Report on Compliance (ROC) is most applicable to your business.
Answer a few short questions and we’ll help identify your compliance level.
Does your business offer services to customers who are interested in your level of PCI compliance?
Identify your PCI SAQ or ROC level
The PCI Security Standards Council has established the below criteria for Merchant and Service Provider validation. Use these descriptions to help determine the SAQ or ROC that best applies to your organization.
Good news! Vanta supports all of the following compliance levels:
A SAQ A is required for Merchants that do not require the physical presence of a credit card (like an eCommerce, mail, or telephone purchase). This means that the Merchant’s business has fully outsourced all cardholder data processing to PCI DSS compliant third party Service Providers, with no electronic storage, processing, or transmission of any cardholder data on the Merchant’s system or premises.
Get PCI DSS certified
A SAQ A-EP is similar to a SAQ A, but is a requirement for Merchants that don't receive cardholder data, but control how cardholder data is redirected to a PCI DSS validated third-party payment processor.
Learn more about eCommerce PCI
A SAQ D includes over 200 requirements and covers the entirety of PCI DSS compliance. If you are a Service Provider, a SAQ D is the only SAQ you’re eligible to complete.
Use our PCI checklist
A Report on Compliance (ROC) is an annual assessment that determines your organization’s ability to protect cardholder data. If you’re a Merchant that processes over six million transactions annually or a Service Provider that processes more than 300,000 transactions annually, your organization is responsible for both a ROC and an Attestation of Compliance (AOC).
Automate your ROC and AOC