ISMS Security Incident Management Process
1. Purpose, Scope and User
This document defines the process how VSHN handles security events and vulnerabilities.
Further it defines the objectives and processes to for threat intelligence.
2. Definition of a Security Incident
An information security incident is "a single or a series of unwanted or unexpected information security event that have a significant probability of compromising business processes and threatening information security" of VSHN data or systems.
Golden Rule: Report every suspicious event. It is better to report one event too many than to miss a critical incident. When in doubt, it’s an event.
3. Triggers of a Security Incident
Triggers include, but are not limited to:
Hardware Loss: Theft or loss of laptops, mobile devices, or access badges.
Unauthorized Access: Suspected account compromise or unauthorized physical entry.
Malware & Phishing: Successful or highly targeted attacks.
Data Leaks: Accidental disclosure of credentials, keys, or customer data.
CIA Suspicion: Any other situation where security appears at risk.
4. Report Security Incident
If you observe a potential incident, act immediately.
All incidents must be reported to the CISO or the ISM Governance Role.
The observer creates a security incident ticket according to How to Create Security Incident Tickets.
The observer ensures that the CISO or the ISM Governance Role is aware of the ticket and that immediate measures are applied if needed.
5. Treatment
First an initial assessment must be done, then work through bullet points according to classification.
5.1. Initial Assessment
The CISO ensures:
Assessment of the incident and whether immediate measures are needed:
Organize immediate measures in coordination with the Operations engineers of the team responsible for the affected service.
Define a ticket owner.
Classification of the incident in four categories:
Security vulnerability or event - no incident has occurred, but the event related to a system, process or organization could result in an incident in future.
Minor Incident - an incident that doesn’t have a significant impact on the confidentiality or integrity of information and can’t cause a longer-term loss of availability.
Major Incident - an incident that could cause significant damage through the loss of confidentiality or integrity of information, or that could cause an interruption in the availability of information or processes for an unacceptable period of time.
Incident endangering the business continuity - a serious incident that could endanger the existence of VSHN.
5.2. Security Vulnerabilities or Events
The CISO analyzes the information, determines the cause and, if necessary, proposes preventive and corrective measures.
All actions must be recorded in the ticket system.
5.3. Minor and Major Incidents
If a minor incident is reported, following steps must be done:
Take measures to isolate the incident.
Analysis of the causes of the incident.
Take corrective action to eliminate the cause of the incident.
Informing those affected by the incident and the ISM Governance Role about the procedure for handling the incident.
If customers are involved then Customer Account Manager must be involved and must assess whether they should inform the customer.
If there is a bigger incident with involving customer, Customer Account Manager, CISO, and ISM Governance Role should find out whether a communication on C-level to C-level is needed and find a person that could represent VSHN’s C-level.
The assignee of the ticket must document taken actions in the ticket system.
5.4. Incidents that Endanger the Progress of Business
In the event of incidents that endanger the progress of business, an BCM Plan comes into effect.
The assignee of the ticket must document taken actions in the ticket system.
6. Learning from Incidents
The CISO ensures each incident is analyzed and documented in the incident ticket according to the following points:
identification of the type
origin / root cause of an incident
and cost of an incident
The CISO must review all incidents on a quarterly basis and propose appropriate preventive or corrective measures for those that recur (or those that could become significant incidents the next time they recur). The verification is ensured by the recurring ticket ISMS-181 and documented in the VSHN’s wiki.
6.1. Post-mortem
A post mortem must be created according to the post mortem template if the incident is major or more severe. If customers are involved Customer Account Manager and CISO will decide whether a post-mortem should be created for minor or less severe incidents. Involved customers must receive the post-mortem
7. Threat Intelligence
The objective of VSHN’s threat intelligence is to ensure that VSHN remains updated on potential threats and can effectively communicate this information to employees working on the front line.
The CISO is responsible for analyzing new potential threats during the quarterly review required in Learning from Incidents section. The following three layers of threats should be analyzed:
Strategic threat intelligence (high-level information about the changing threat landscape)
Tactical threat intelligence (information about attacker methodologies, tools and technologies)
Operational threat intelligence
For strategic and tactical intelligence analysis, the CISO utilizes sources documented in Security and Vulnerability Handling Process; this list may be expanded or modified during the analysis process. Operational intelligence is gained from the incidents documented by VSHN and other relevant sources. A summary is quarterly documented in Annex - Quarterly Review of Security Incidents with the ticket ISMS-181. The CISO is responsible for deciding whom to communicate the findings to and to define follow-up tickets to be looked at by VSHN’s teams.
8. Disciplinary Measures
The People Role may initiate disciplinary processes for any violation of security rules.
9. Collection of Evidence
If there is a suspicion that an incident occurred due to criminal activities, evidence must be secured immediately. For this purpose, external partners such as Swiss FTS are called in who have the necessary expertise in handling evidence. The CISO is responsible for the coordination.
10. Reference Documents
| ISO 27001:2022 | Control |
|---|---|
A.5.7 | Threat intelligence |
A.5.24 | Information security incident management planning and preparation |
A.5.25 | Assessment and decision on information security events |
A.5.26 | Response to information security incidents |
A.5.27 | Learning from information security incidents |
A.5.28 | Collection of evidence |
A.6.4 | Disciplinary Process |
A.6.8 | Information security event reporting |
11. Appendix
Incidents blocking ticket ISMS-243
Related process Security and Vulnerability Handling Process
Last reviewed | 2026-06-02 with ISMS-2003 |
|---|