I have spent a good bit of my time over the past few months helping customers with risk assessments. Since many of the major regulatory frameworks, including HIPAA, PCI, and SSAE 16, all call for them, organizations have been forced, some kicking and screaming, to engage in reviewing their risks.\u00a0Many companies treat the requirement for a completed risk assessment as a an exercise in \u201cpapering the file\u201d \u2013 it must be done, so get through it as fast as possible, put it on file, and move on to something important. I don\u2019t find this surprising, given that the guidance provided as part of the requirements is either minimal, or impossibly confusing. For example:\u00a0HIPAA\u00a0Section 164.308(a)(1)(ii)(A) has only 23 words on the subject; PCI 12.1.2 has 15; and SSAE 16 makes only general references.A simple Internet search on the subject provides a wide variety of responses, many of which are quite complex. As an example, "Harmonized Threat and Risk Assessment," which I use as a basis for much of my methodology, is 290 pages. To make matters more confusing, various standards for risk assessment exist, including OCTAVE, ISO 27005, and NIST SP-800-30.\u00a0A risk assessment can clearly be an intimidating process.While I realize that performing a risk assessment is less fun than a visit to the dentist, it can be an essential and relatively painless process.\u00a0Let\u2019s start with defining \u201crisk\u201d in this context. According to the\u00a0PCI DSS Risk Assessment\u00a0Guidelines, risk is \u201ca function of the likelihood of a given threat-source\u2019s exercising a particular potential vulnerability and the resulting impact of that adverse event on the organization.\u201d\u00a0 This may seem like a rather nebulous definition, but it contains the key elements involved in assessment of risk:\u00a0Threat \u2013 put simply, something bad that might happen. A threat generally cannot be prevented. It just exists, and therefore must be addressed.\u00a0Threat Source \u2013 the \u201cactor(s)\u201d that generate a threat. A threat source is not necessarily a person; it could be an act of nature.\u00a0Vulnerability \u2013 a weakness or exposure that might be exploited by a threat. This might be a software design failure, access control error, or anything that might serve as window through which a threat might "jump.\u201d\u00a0 Generally, a vulnerability can be eliminated or mitigated in some way.\u00a0Asset \u2013 the things we must protect from threats. This is a broad term, including systems, people, data, or anything of value to an organization.\u00a0A risk assessment therefore, identifies risks generated by the possibility of threats acting on vulnerabilities, and what can be done to mitigate each one. Formal risk assessments come in two flavors: quantitative \u2013 involving specific dollar estimates resulting from any risk being realized; and qualitative \u2013 involving the use of scoring to rank order risks, without attempting to specifically quantify the dollar loss. Most organizations attempting to comply with HIPPA, PCI, etc will perform a qualitative assessment, because they find it genuinely impossible to arrive at an accurate dollar figure.\u00a0With these simplified definitions in mind, we can lay out a practical process for assessing risks qualitatively.Identify your assetsWhat \u201cthings\u201d do you have that, if compromised, would cause harm to your organization? List them, along with appropriate details, like location and owner. In the case of organizations with many assets, I like to aggregate them for a risk assessment. For example, if you have four web servers splitting traffic for an eCommerce application, you can treat the four as a single asset.\u00a0Identify threat sourcesWhat are the \u201cactors\u201d that can produce a threat. As I said above, this can be, but is not limited to, people. Sources can include hackers, the government, competitors, etc. List them.\u00a0Identify threatsFrom your list of sources, you can begin to identify your threats. Think broadly here, because this can include a wide variety of potential issues. Some examples include fraud, server failure and loss of utilities . List your threats, and link them to the related source(s).\u00a0VulnerabilitiesThinking about your list of threats, consider what occurrences (intentional or accidental) could take advantage of them to cause harm to your organization. Again, this is a broad category, and can include intentional and unintentional situations. Examples include change control failure, or phishing attack. List them, and tie them to one or more related threats.\u00a0Score the resultsThere are various means of scoring threats and risks. I like to use a four point scale, with one being a minimal issue, and four being critical. I score each threat using this scale for likelihood (what is the realistic chance of that threat impacting the organization), and then impact (how bad it would be if the threat occurred). I average the two, do the same for vulnerabilities, and then average the score for a vulnerability with the highest score for a related threat. The result is the risk score.\u00a0While everything with a non-zero score is a risk, the items with a risk score of 1 or 2 generally do not have to be specifically addressed. Anything with a 3 or 4 needs to have a mitigation plan established. This simply identifies how you plan to address the risk. This can involve a technical or policy change, or can simply be the statement that the organization will accept the risk, since there is no practical mitigation strategy. Items with a risk score of 4 should be addressed immediately, as they represent an eminent and significant threats.\u00a0Once complete, the process should be updated at least yearly, although I recommend making this a living process, to be evaluated and updated continuously.\u00a0Bottom line \u2013 if you must comply with any of the regulatory standards, a risk assessment is a requirement. Rather than seeing it as a necessary evil, treat it as the useful process it can be.