An incident was logged as low severity when a laptop was reported stolen. Two days later, investigators learn the laptop held unencrypted customer records. What should happen to the incident's classification?
Select an answer to reveal the explanation.
Short Explanation
Classification isn't carved in stone; it's a best guess that gets better as you learn more. Once you know customer data was on that laptop, the severity goes up and the escalation and notification steps kick in. Waiting for proof of access is the trap; by then you may have missed the window.
Full Explanation
Initial classification is made with limited information and must be revisited as facts emerge. Learning that a stolen device held unencrypted customer records changes the potential impact significantly, bringing in privacy, legal and possibly regulatory notification considerations. The incident should be reclassified to the appropriate severity, which in turn triggers the escalation paths, stakeholder involvement and decisions defined for that level. Keeping the original severity to protect metrics puts reporting convenience ahead of response, and metrics should record reclassification rather than prevent it. Closing the incident and opening an unlinked one breaks the record of what happened and when, which undermines the investigation, the timeline for notification decisions and later review. Waiting until access is proven ignores that severity reflects potential as well as actual impact; many notification frameworks require assessment of the risk of harm, and delay can cause the organization to miss required time frames. Exam caveat: the decision whether notification is required belongs to legal and privacy functions, and reclassification is what brings them in promptly. Operational check: confirm the incident record shows the reclassification time, the reason, and when legal and privacy were engaged.