Misdirected Pricing File and a Stale Exchange Rate
Northwind Components is a 180-person manufacturer that quotes machined parts to industrial customers. On a Tuesday, a sales analyst emails a file named Q3-price-list-final.xlsx to what she believes is a customer's procurement address; the domain is one character off and the mailbox belongs to a competitor's reseller. The file contains customer-specific discount tiers and gross margins. The same week, the finance team discovers that the ERP-to-spreadsheet export had stopped refreshing the EUR/USD rate, so quotes issued over three days used a rate that was 4% out of date. Nobody outside the company saw those quotes. Both events are logged by the service desk as 'user error' with no further action, and the security officer is asked to write a one-page note for the management review explaining what actually happened and whether either event belongs in the incident register.
1. Explain the difference between data and information in this scenario, and identify which element of the CIA triad each event affects. Is the stale exchange rate an availability problem?
Read the worked answer
Data vs information. The spreadsheet's rows, cells and numbers are data; the information is what those numbers mean when used - which customer gets which discount tier and what margin the company will earn. Security protects the information, and the data is only the carrier.
Event 1 - misdirected email: confidentiality. An unauthorised party (the reseller) has received commercially sensitive pricing and margin data, whether or not anyone opens it. Disclosure has already happened at the moment of sending.
Event 2 - stale exchange rate: integrity. The quotes were available and usable, but they were wrong. Availability means the information is accessible when an authorised user needs it; it does not mean it is correct. Accuracy and completeness belong to integrity.
Why the distinction matters. The two events need different responses: the email needs containment and possibly contractual notification, while the rate needs reconciliation, re-pricing of affected quotes and a control on the export. Labelling both 'user error' conflates the cause with the effect and hides this difference.
2. Both events are currently logged as 'user error' with no further action. Should they be entered in the incident register, and how would you assign severity?
Read the worked answer
Yes, both belong in the register. An information security incident is a security event that has an actual adverse effect on confidentiality, integrity or availability. Both qualify: one disclosed data, the other produced incorrect financial information. Near misses can be logged separately, but these are not near misses.
Severity is driven by impact, not cause. 'User error' describes how it happened; it says nothing about harm. For the email, ask: how sensitive (discount tiers and margins - high commercial value), who received it (an external reseller - uncontrolled), how many customers are listed, and does a contract require notification? That points to a medium-to-high rating and escalation to management.
For the rate error, ask: how many quotes, what is the margin exposure at 4%, and can the quotes be withdrawn? Impact is financial and internal, so probably medium, with a lower confidentiality dimension.
Record for each: asset and owner, date, description, CIA impact, root cause, containment, corrective action, and closure criteria. Severity scales should be defined in the policy so that 'high' means the same thing to everyone.
3. The service desk manager argues that closing these as 'user error' is enough because nobody was harmed. Give two reasons why that position is weak for management reporting.
Read the worked answer
First, it stops the analysis too early. 'User error' is a contributing cause, not a root cause. The email was possible because the mail client auto-completed an external address and the file carried no classification marking; the rate error was possible because the export had no reconciliation check. Neither is fixed by reminding one person to be careful, so the same event will recur.
Second, it removes the information management needs. Management cannot prioritise spending on awareness, data-loss prevention or monitoring if the only reported category is 'human mistake'. Aggregating incidents by cause is useful, but only alongside impact and affected assets.
A fair caveat: user error is genuinely common and a blame-free register encourages reporting. That argues for recording it as a contributing factor and still logging the incident - not for suppressing the record. The note should also state whether either event triggers a contractual or legal notification obligation, which the service desk is not positioned to judge.