incidents<\/a> are highly visible to your users (i.e., people using your services) and customers (i.e., those who pay for using your services). Take e-mail service as an example. Can you imagine how your users would feel if or when that service became unavailable? Actually, you don\u2019t have to do that, because you know the answer. And, they would have the same feelings if their e-mail service started having interruptions or malfunctions, i.e., incidents started to occur.<\/p>\nAnd, you know what? Incidents could get worse \u2013 when they are security related. Basically, security-related incidents mean that not all incidents are the same. Let me get back to the e-mail service example again. A security-related example would mean that, e.g., someone\u2019s account is compromised, meaning an unauthorized person has access to it, or that a lot of SPAM is sent from someone\u2019s corporate account. In both cases the issue is not only that, e.g., that user can\u2019t use the service for some time (that would be a case when a \u201cnormal\u201d incident occurs), but that the company could have a significant financial loss (e.g., sensitive data are revealed because an unauthorized person has access to the e-mail account) or all corporate e-mails are banned by SPAM filters due to unsolicited e-mail that is sent.
\n
<\/div>