One thing that might be good when analyzing assets (and the risk associated with them) would be to add an option to include the number of records associated with that asset.
This can help when doing risk analysis, as the number of records held by an asset (and the types of records, such as PHI, PII, financial, etc.) would be a good measure of how much liability there might be if that system was breached/impacted.
Yes, basically. Could be defined by the user themselves.
Specifically, I would look at using it to document how many records of a certain type we hold in each system. This would include things (in the US, at least) like number of social security numbers (Personally Identifiable Information), number of records with Protected Health Information, or just number of company confidential records.
No, no sorry, not Eramba system records. Here’s an example of what I mean:
Say we’re talking about an Electronic Medical Record (EMR) system for example. Also, say we know we have records of approximately 80,000 individual patients in this EMR. The risk of this system is high, as it maintains a LOT of PHI.
Now, say we have a system that contains only 200 records of Personally Identifiable Information (PII). This system has much lower risk, as it has less records. It also has a different type/set of records.
Therefore, the way I risk analyze each, suggest different controls, calculate risk scores, etc. is different between each system, and can be based on the total number of records in each asset/system.
Also, I can then potentially calculate cost impact of a breach of each system. I can use the Ponemon Institute’s 2017 Data Breach study report numbers to calculate what it might cost if data was breached in each system (based on # of records). The 2017 report can be found here: Cost of a data breach 2022 | IBM
In the 2017 report, it states that healthcare records cost $380 per record breached. So, I can estimate the cost impact of a breach of our EMR at 80,000 records * $380 per record = $30,400,000 in possible loss.
Hopefully I was able to be more clear/less vague this time.