ISO/IEC 27035: The Incident Security Incident Management Guide

1.Purpose and Scope: In this article, we will learn about the security incident phases, security incidents response planning (IRP), Incident Response Team Structures, and assist organizations in mitigating the risks. These proactive practical approaches and guidelines help both public and private sectors in preparing, detecting, analyzing, remediate, recovering, and post-incident analysis. We can able to use the suggested, use cases, guidelines, and solutions to meet and adjust according to our specific security and mission requirements. It has become an eminent component of information technology (IT) programs. Like a Big-Bang expansion, Cybersecurity-related attacks continually evolving, also causing more damage to the entities. Therefore every organization needs to have a consistent Incident Response Plan (IRP) and incident management skills, to mitigate the weaknesses, keeping the business running, minimizing loss and reputation based on the results of risk assessments. Through this way it helps to lower the occurring incidents, also to be remembered not all incidents can be prevented. This provides the guidelines, techniques, and best practices in Information security incident management release for large and medium-sized organizations. In addition to that small-sized organizations can follow the basic set of procedures, and recommended international incident management practices, also you may offer external parties to take care of the information security incidents. ISO (27035:2016) International Standard 1.1Incident management Basic Concepts: Must know it, buddy! The following concepts, terms & definitions are indispensable of incident management. So, let's take a quick catch-up with it before we get into this article. Security incident: A security incident is an event identified when it occurred on a system or network indicating a possible breach of the CIA triad. These unexpected events could have caused significant damage to the organization, compromising business operations, and leaking sensitive data to the public. The occurrence of events can be categorized according to the CIA triad objectives. Information Asset: An asset is anything valuable to an organization. An asset can be classified according to the type of assets which you are trying to protect. While classifying the assets consider their value, age, locations, law, and exposure to the public. After that, you can come with the plan on the required time, money, manpower to secure those classified assets in your organizations. Vulnerability: A vulnerability is a weakness or flaws present in a system, design, or a network eventually that could be exploited by a threat actor. Threat: A threat an unwanted action imposed by a threat actor when he finds a way to exploit a vulnerability in the system or a network. When exploited threat poses an immense danger to the assets. Exploit: A threat actor performs exploitation when he managed to craft a set of arbitrary codes to exploit the vulnerability on a system. Countermeasure: We will be in this position to do this. when we perform the risk assessment to understand more about the discovered vulnerabilities. In this stage, we will apply countermeasures to eliminate or reduce the vulnerability severances in the system. Figure 2. Information Security Incident Chain. 1.2 Participating Teams: Figure 3. Types of Security response team.2. Five Key-Phases of Information security incident management guide a.k.a Principles of incident management. There are two perspectives to consider one is organization’s overall security strategy should be put forthwith necessary controls and procedures, and the second one is business perspective to reduce or contain the impact caused by security incidents. These information security incident management practices are defined in 5 standard phases. Figure 4.ISO/IEC 27035: Information security incident management. Benefits of a 5 Key-Phases: Improving overall information security. Reducing adverse business impacts. Strengthening the information security incident prevention focus. Strengthening prioritization. Strengthening evidence. Contributing to budget and resource justifications. Improving updates to information security risk assessment. Providing enhanced security awareness and training. Adding input to information security policy. 2.1 Plan and prepare phase: The overview of key activities in this phase is to plan and prepare an appropriate plan for the incident management policy, also consider including the event management, vulnerability management schemes into this phase, and finally get the executive members to fully committed to that policy to be effective upon the implementation. Again consistency is vital to success, regularly updating the information security and risk management policies is essential and should be applied at all systems, departments, and network levels. When there is an event, the responsible person should document detailed security incident information according to the management scheme. This document contains overall procedures, policy, operating tools, templates, roles & responsibilities. The topics for inclusion include: a) Information security events are classified based on the incident classification scale to be used to grade any occurred incidents. In such incidents, the decision should be based on the actual or projected adverse impacts on the business operations. b) The “security event/incident/vulnerability forms”, should be processed and completed only by the person who is handling it. c) Initially reported information is kept running in the database and at each stage when there is an update it’s recorded in the “information security event/incident/vulnerability “, database. d) When there is a vulnerability discovered in the incident, it’s reported and recorded by the person reporting. e) When Operating procedures are affected by the incident. (I) Shut down an affected system, service, and/or network, (ii) leave an affected connected system, services running, and/or network. (iii) To monitor data flowing from, within an affected system, service, and/or network. (iv) to initiate back-up and crisis management procedures. (v) To secure and preserve all electronic evidence for legal and lawful purposes. (vi) To publically disclosure the incidents and share them with internal and external organizations. f) To conduct an appropriate training program for members of the team. g) To establish and preserve transparent relationships between internal and external organizations that are directly involved in information security events. h) To reduce and prevent security incident occurrences follow the mechanisms. Figure 5. Internal information security audit mechanisms. i) To design and develop an information security event, incident and vulnerability management framework, and training program. j) To test the use of the information security incident management plans. 2.1.1 Information security incident management integration in other policies: Every organization should document the security events, incidents, vulnerabilities according to the formulated information security management Policy. The policy can be adjusted based on the size of the organization and reviewed fully before its implemented officially. An organization should make sure the incident policy and, risk management is approved by the executive members and the suggested policies cover all levels such as system, services, and network resources. If you would like to learn more about “Risk management” don’t forget to check ISO/IEC 27005:2008. The following checklist helps you to verify it. a) To describe why information security incident management and information security incident plan, is crucial to the organization. b) To request for a senior management firm decision in need of proper preparation and response to information security incidents. c) To ensure consistency across the various policies. d) To ensure planned, systematic approaches are in the actions in minimizing the impacts. 2.1.2 Information security incident management scheme: It helps to provide a detailed process describing the necessary work-flows and procedures for dealing with information security events and incidents, and the communication of such events, incidents, and vulnerabilities. a) Quickly respond to any information security events. b) To determine whether security events become security incidents at any point. c) To managing information security incidents to a conclusion, d) Quickly respond to information security vulnerabilities, e) Summarize the lessons learned, and find any improvements to be added to the scheme. f) Applying the changes to the scheme. 2.1.3 Establishment of the Information Security Incident Response Team (ISIRT): To establish an Information Security Incident Response Team to help the organization on identifying, assessing, and responding to any security incidents, coordinating with other departments, process feedback, and close the case. The ISIRT team reduces the damage to the organization, prevents monetary damage associated with the data leak or lawsuits. The size, structure, and of an ISIRT should be determined by the management of the organization. The ISIRT manager should have a separate point of contact (POC) channel for the senior management members in the event of security incidents to receive commands that’s helpful in decision making. So, the ISIRT managers must acquire all the skills knowledge, and recent trends in the field to drive the team on the right path. 2.1.4 Establish Relationship with external interested parties: Figure 6. Establish a relationship with external interested parties. 2.1.5 Technical and other support (including operational support): To act quickly and respond to security incidents organizations should acquire, prepare and test all necessary technical and other support departments. a) Get access to details of the information assets with an up-to-date asset ledger and information on their links to organization business functions. b) Crisis management document and procedures. c) A clear annunciation of their policy, document, and communication channels. d) Feed security event/incident/vulnerability into the centralized database and new events are updated to the database quickly, and protect the database securely. e) Have sufficient tools for information security forensics evidence collection and analysis, f) Adequate business continuity management plans. 2.1.6 Awareness and training: Both private and public sector organizations should instigate competent training programs, and encourage their employees to understand that security is a its . “ single person’s job ” “ everyone’s job ” The training and program are crucial for one organization’s success in incident management. The executives and senior leader must understand training is received by everyone and relevant resources are available to all persons including the newly joined employees, 3rd party users, and business-related contractors. 2.2 Identifying, Detecting, and Reporting phase: In the first phase of the incident management, the operational phase is the first phase, that process is on detecting, collecting information associated with security incidents, and reporting on security incidents. To ensure appropriate personnel is assigned to deal with reporting security vulnerabilities are recorded in the database as like how non-information security faults are handled. Figure 7. Information security event and incident flow diagram. These operations are processed by a human and through an automation process. Every organization should ensure the following key activities are performed in this phase. a) To detect and report the occurrence of security events and vulnerability presence or exist in the organization’s products & services, customers, employees, contractors components, and network resources. Setting up network traps such as (honeypots, honey tokens, honey clients, tarpit) based systems to securely monitor intruder presence on the network and to deceive, distract, encourage the intruder to operate on the fabricated materials for denial operations. Overall security alerts from network monitoring systems such as firewalls, traffic flow analysis, web filtering, and another system. To analyze log information from devices, services, hosts, and network systems. To evaluate anomalous events detected by ICT. To evaluate anomalous events detected by help desks. To check user reports, and external notifications coming from third parties such as other ISIRTs, information security services, ISPs, telecoms service providers, outsourcing companies, government ISIRTs. b) To collect information about security events or vulnerabilities. c) To ensure that all PoC’s are properly logging all activities, results, and related decisions for later analysis and review purpose. d) To ensure that electronic data is gathered, stored, preserved securely, and required data has been kept for legal purposes. e) To ensure that the change control program is maintained and updated actively. f) To raise a ticket, on an as-required basis throughout the phase, and g) To register in an Incident Tracking System. 2.2.1 Event detection: All types of physical security events could be detected directly by the person in charge of the duty. That being said, technical security events are detected automatically with the help of signature and anomaly-based parameters. when there is a concern on a likelihood should follow the procedures and consult with the other members of the team for clearance. → users. → line managers and security managers. → customers. → IT department, including Network Operations Center and Security Operations Center) IT help desk. → Service providers (including ISPs, telecom, and suppliers). → The ISIRT. → other units detecting anomalies during their daily work. → mass media and → websites for disclosure, bug county, blogs, etc.,. 2.2.2 Event reporting : The responsible members of the team should follow the defined procedures, open access to the available PoC’s, and use the reporting templates to register the new events. Reporting elements: → Time/date for detection, → Observations, and → Contact information (optional). 2.3 Assessment and decision phase: The third phase of the incident management program involves the assessment of information associated with security events and prepare for the decision based on the following key activities. To conduct an assessment to determine whether the security event is in a likelihood or in a false positive state, or its concluded. The ISIRT to conduct an assessment to confirm the results of the PoC’s assessment findings to understand whether the incident is true or false. based on the results secondary assessment should be conducted. a) Activities to ensure throughout the phase, for further assessments and decision operations. b) To collect information about security events or vulnerabilities. c) To ensure that all PoC’s are properly logging all activities, results, and related decisions for later analysis and review purpose. d) To ensure that electronic data is gathered, stored, preserved securely, and required data has been kept for legal purposes. e) To ensure that the change control program is maintained and updated actively. f) To raise a ticket, on an as-required basis throughout the phase, and g) To register in an Incident Tracking System. h) To distribute the security incident management activities and responsibilities evenly to the responsible persons through an appropriate hierarchy of responsibility with the assessment. i) To provide carry out procedures including reviewing, amending changes to the report made, assessing the damage, and notifying the relevant personnel for further actions to be made. 2.3.1 Assessment and decision making elements of PoC: a) What was seen and done that includes the list of software and tools operated. b) The location of the potential evidence, c) How evidence is archived (if applicable), d) How evidence verification was performed (if applicable), and e) Details of storage/safe custody of material and subsequent access to it. 2.3.2 Assessment and incident confirmation by the ISIRT: After the assessment, and confirmation of each decisionISIRT responsibility it whether a detected security event is to be classified as a security incident or not, should be the responsibility of the ISIRT. The receiving person in the ISIRT should do the following: a) Acknowledge receipt of the security incident form and complete the PoC. b) Feed the form into the security event database if it was not fed by the PoC team members and be sure to update it to the database if necessary. c) If it’s required, Seek clarification and suggestions from the PoC members. d) Review the reporting form content. e) Collect any further information required and known to be available. 2.4 Responses phase: The fourth phase of the incident management program is response operation. All responses are made based on the output from the decision phase, responses could be made immediately on a real-time basis or within the decided time-frame with the help of forensic analysis operations. In the responses phase, an organization should ensure that the key activities are the following: a) The ISIRT review and determine if the security incident is under control, and activity below: Required response formal process begins. This could be an immediate response, which involves activation of recovery procedures, and issuing commands relevant to responsible personnel, or later approaching the full recovery from a disaster. After that ensuring all information is ready for post-incident review activities. Instigating earlier is better because if the crisis is not under control which going to cause a severe impact on the business services. b) To align and identify internal/external resources in order to respond to an incident. c) To conduct security forensics analysis, and security incident classification to scale the rating, and modify the rating as necessary. d) To escalate, on an as-required basis throughout the phase, for further assessments and/or decision-making process. e) To ensure that all log all activities are recorded for later analysis. f) To ensure that electronic evidence is gathered and stored securely at the rest/in motion/on transfer, and preservation monitoring is processed, continuously in case it is required for legal actions. g) To ensure that the change control program is followed through the life cycle on security incident tracking, reporting, updating, and thus that the security event/incident/vulnerability database is kept up-to-date for operations. h) To communicate the existence of the security incident and relevant details therefore other internal and external members such as (asset/information/service owners) of the organizations, in particular, asset/information/service owners will be helpful in the determination, management, and resolution of the incident. Once the security incident has been determined and the desired responses are agreed upon, the subsequent activities should be in place as stated: a) To distribute the responsibility for incident management activities through an appropriate hierarchy of channels for decision-making. b) To provide formal procedures for each involved person to follow, including reviewing and amending reports made, re-assess the damage, and notify the relevant personnel. c) Activity to use guidelines for a thorough documentation of an information security incident, of the subsequent actions, and updating of the security event/incident/vulnerability database. d) To document the subsequent actions. e) To regularly update the information security event/incident/vulnerability database. 2.4.1 Immediate responses: The primary goal of the security incident management program and associated actions to minimize the business impacts, whereas identification of the attacker should be considered a secondary goal. The response objectives in responding to information security incidents are the following: a) To confine the potential adverse impacts. b) To improve information security. While undertaking such a decision, things to consider that the attacker may realize that his actions are being observed and may undertake actions that cause further damage to the affected information system, service and/or network, and related data, and the attacker could further deteriorate the data that may be useful to track the origin of the attack. It is essential to understand possible technical measures to take quickly and reliably cut-off, and/or shut down the attacked information system, service, and/or network, once a decision had been taken. This serves to contain the incident. 2.4.2 Incident information update: a) What the information security incident is about. b) How it was caused define in reasons, and by what or whom, c) What it affects or could affect further on transfer. d) The impact or potential impact to the business service. e) Security incident is deemed significant or not determined according to the pre-determined severity scale. f) How it has been dealt with so far. 2.4.3 Responses to crisis situations: a) The required preventive, resilience, and crisis management measures to be taken. b) The required organizational structure and responsibilities for responding to crisis situations, and c) The required structure and outline content for the crisis management plan. 2.4.4 Information security forensics analysis: a) To ensure that the target system, service, and/or network is protected during the forensic analysis. b) To prioritize the acquisition and collection of evidence such as proceeding from the most volatile to the least volatile. c) To identify all relevant files on the subject system, service, and/or network, including files, passwords, protected data, and encrypted files. d) To recover as much as possible discovered deleted files and other data through file integrity monitoring (FIM) services. e) To discover IP addresses, hostnames, network routers, and website information. f) To extract the contents of hidden, temporary, and swap files used by both application and operating system software. g) To access the contents of protected or encrypted files. h) To analyze all possibly relevant data found in the special disc storage areas. i) To analyze file access, modification, and creation times. j) To analyze system/service/network and application logs. k) To determine the activity of users and/or applications on a system/service/network. l) To analyze e-mails for source information and content. m) To perform file integrity checks to detect Trojan horse files and files not originally on the system. n) To analyze, if applicable, physical evidence, for example, fingerprints, property damage, video surveillance, alarm system logs, pass card access logs, and interview witnesses. o) To ensure that extracted potential evidence is handled and stored in such a way that it cannot be damaged or rendered unusable. p) To conclude on the reasons for the security incident, and the required actions required, along with lists of relevant evidence to the main report. q) To provide expert support to any disciplinary or legal action as required. 2.4.5 Internal and External Communications: It should be taken to ensure who needs to know what and when. When it comes to stakeholders that are affected should be determined and preferably divided into groups such as: a) Direct internal stakeholders (crises management, management staff, etc.), b) Direct external stakeholders (owners, customers, partners, suppliers, etc.), and c) Other external contacts such as press and/or other media. 2.4.6 Escalation: In extreme circumstances, matters may have to be escalated to accommodate incidents that are out of control and pose a potential danger for unacceptable business impacts. This type of incident needs to be escalated to activate the business continuity plan (BCP). Follow the guidance on information security incident management programs and inform members of those who are likely at some point to need to escalate matters such as PoC and ISIRT members. 2.4.7 Activity logging and change control: To properly log all types of activities for later analysis. It should be included in the security reporting form and continually kept up to date throughout the cycle of security incidents from the moment of reporting to the post-incident analysis and closure. It should be retained securely with an appropriate backup and DRP programs. 2.5 Lessons learned phase: Overview of key activities includes information security forensic analysis, Identifying the lessons learned, making improvements to information security control implementation and information security risk assessment and management review results, information security incident management program, and Other improvements. The final phase of the information security incident management program follows when security incidents have been resolved/closed and involves learning the lessons from how incidents and certain vulnerabilities have been handled and dealt with in the timeframe. For the lessons learned phase, an organization should ensure that the key activities are the following: a) To conduct further information security forensics analysis, as required. b) To identify the lessons learned from information security incidents and vulnerabilities. c) To review, identify and make improvements to information security control, implementation, policies, as a result of the lessons learned. d) To review, identify and make improvements to the organization’s existing information security risk assessment and management review results, as a result of the lessons learned. e) To review how effective the processes, procedures, the reporting template structure were helpful in responding to, assessing, and recovering from each information security incident and brief the required changes in the report. f) To update the information security event/incident/vulnerability in the database. g) To communicate and share the results of the review within a trusted community. Conclusion: In this article, we discussed the security incident phases, security incidents response planning (IRP), Incident Response Team Structures, and assist organizations in mitigating the risks. These proactive practical approaches and guidelines help both public and private sectors in preparing, detecting, analyzing, remediate, recovering, and post-incident analysis. These four areas are part of the ISO 27035:2016 draft (Principles of incident management, Guidelines to plan and prepare for incident response, ICT incident response operations, and Coordination). — — — — — — — — — — — — — - — — — — — — — — — — — — THE END Quote of the day: γηράσκω δ᾽ αἰεὶ πολλὰ διδασκόμενος ( Gēraskō d’ aíeí pollâ didaskómenos). I grow old always learning many things. Explanation: Thanks for reading! Have a pleasant day! Previously published at https://gtmars.medium.com/how-to-plan-detect-assess-and-respond-to-information-security-incidents-by-using-iso-iec-27035-ed744c8b7cd5

ISO/IEC 27035: The Incident Security Incident Management Guide

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Deploying AES Encryption On Cryptool 2.1

The TechBeat: Cardano’s 14-Hour Stress Test: How the Network Took a Hit and Healed Itself (12/5/2025)

Secure Legion Launches First Metadata-Free Messenger with Zero Servers

The Invisible Breach: How AI Is Quietly Creating New Security Blind Spots in Modern Tech

SpyCloud Data Shows Corporate Users 3x More Likely to Be Targeted by Phishing Than By Malware

The TechBeat: Porting Scientific Algorithms from MATLAB to JavaScript (12/4/2025)

Deploying AES Encryption On Cryptool 2.1

The TechBeat: Cardano’s 14-Hour Stress Test: How the Network Took a Hit and Healed Itself (12/5/2025)

Secure Legion Launches First Metadata-Free Messenger with Zero Servers

The Invisible Breach: How AI Is Quietly Creating New Security Blind Spots in Modern Tech

SpyCloud Data Shows Corporate Users 3x More Likely to Be Targeted by Phishing Than By Malware

The TechBeat: Porting Scientific Algorithms from MATLAB to JavaScript (12/4/2025)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps