In basic terms, a company’s “risk appetite” is the level of risk the organization sees as acceptable. Not surprisingly, some use the phrase “risk tolerance” interchangeably with “risk appetite” (there is an important difference: "tolerance" is how far off "appetite" the organization will go).
I’ve heard it many times – “Why can’t we just do this analysis over the whole IT environment? Why do we need to pick a specific asset or population or assets?”
As a former auditor, I understand the value a control has for an organization, a process or an application. But, I’ll be honest I used to think a control was one dimensional. It didn’t really matter what the control protected, if the control wasn’t functioning properly or configured exactly to a ‘T’, it was failing.
Time and time again I see analysts perform a FAIR risk analysis but get caught up in searching for the absolute perfect data or second guessing the results.
Imagine this – an issue is assigned to your risk analyst team, either by your management, someone in the business, or perhaps it's some area of weakness your own team identified. After completing the analysis, now it's time to prepare a presentation on the risk results.
Army documents marked Top Secret…data on 14 million Verizon customers…voter information on 198 million Americans…Just a few of the recent reports on data breaches—or open data discovered by security researchers before a breach occurred—on Amazon S3 “buckets”.
As a risk consultant, I run a lot of meetings for project scoping or data gathering that bring together people from around a company, usually with different perspectives and agendas. Often these meetings require that everyone come together and agree on a direction for a risk analysis project.
In November, 2016, a Boeing employee emailed his spouse a spreadsheet from work because he needed help with formatting. In the spreadsheet: names, ID numbers, dates of birth and Social Security numbers for 36,000 Boeing employees.