Any compromise of a user account, malware, unauthorised access, ransomware, suspicious network activity, or disruption of critical systems is considered a cybersecurity incident. Once an incident occurs, a structured investigation process must determine what happened, which systems were affected, how the activity occurred, and what actions are needed to contain and recover. An investigation should begin with evidence and not assumptions
If you see an unusual login or an antivirus alert, it could indicate malicious activity, but it might also be legitimate. Therefore, investigators must collect data from the appropriate systems, verify events across multiple data sources, and establish a consistent timeline before concluding. Coordination is also necessary for a successful investigation. Security experts could interact with IT staff, system owners, managers, legal counsel, privacy experts, or outside service providers, depending on the incident’s nature and severity.
Confirm the Incident and Preserve Relevant Evidence
The initial phase of a Cybersecurity investigation involves determining whether an incident occurred and ensuring that data is retained to shed light on what happened. There are numerous ways to get initial evidence. Security alerts, authentication history, application logs, firewall logs, email systems, endpoint protection systems, cloud systems, and employee reports can be highly valuable. Investigators should document the circumstances that led to the investigation, when it was first observed, and which systems or accounts appear to be involved.
Preserving evidence matters because information can be lost in future system changes. Sometimes information that could establish a timeline is lost when a device is restarted, suspicious files are removed, systems are reset immediately, or logs are cleared. So investigators must follow their organisation’s procedure for responding to an incident and handling evidence before making unnecessary changes. If forensic examination is required, a properly trained and qualified expert may need to store system images, logs, or evidence appropriately, in accordance with recognised procedures.
While NIST’s existing incident-response guidance focuses on preparing in advance for effective incident detection, response, and recovery, it also provides comprehensive guidance on responding to likely attacks.NIST’s existing incident-response guidance recognises that an organisation should prepare in advance for effective detection, response, and recovery, but also outlines how to respond to attacks that will likely occur. Start basic documentation as soon as possible. Investigators can document when they found events, who took each action, what evidence they gathered, and what decisions they made. Timestamps are particularly useful when you want to compare information from multiple systems or systems over time.
Determine the Scope and Build an Incident Timeline
If the incident is confirmed, the investigation should determine the extent of the activity. Cybersecurity teams should not assume the first compromised device or account marks the end of the incident. An investigation can start with a single suspicious login and reveal that attackers accessed multiple accounts. If investigators find malware on one workstation, it may indicate the workstation communicated with other systems. Forwarding rules or emails may have been set up or sent to other users from a compromised email account.
Investigators can now cross-check data from multiple authentication logs, endpoint alerts, network logs, cloud services, email systems, and administrative activity. The objective is to discover impacted accounts, devices, applications, data, and external connections. These relationships are easier to understand when built as a timeline. The investigation may log when suspicious authentication was first detected, when privileges changed, when unusual files were seen, and when external communication began.
A timeline should separate assumed events from known events. Investigators may initially form a sequence of events, but new evidence later may alter it. The scope should also consider business impact. A workstation with limited access privileges poses a different risk than an administrative account with access to sensitive databases or critical systems. Unlike other NIST publications, NIST SP 800-61 Rev. 3 integrates incident detection, management, prioritisation, containment, eradication, and recovery into a unified risk-management process.
Contain the Incident and Identify the Likely Cause
Investigation and containment often occur at the same time. When credible evidence shows malicious activity is continuing, Cybersecurity teams may restrict access to the system and determine the cause. Containment can take several forms, depending on the situation. Teams can shut down a compromised account, end suspicious sessions, isolate affected devices from the network or block malicious connections. These actions should follow the organisation’s Incident Response procedures and be coordinated with the appropriate technical and business teams.
To avoid further damage, preserve valuable evidence, and avoid unnecessary disruption to operations. Investigators should then look at where the attacker likely first entered. This may be through stolen credentials, phishing, an exposed remote service, a vulnerable application, misconfigured access permissions, malicious software or other faults. Root cause analysis looks beyond the event. If an employee’s credentials have been stolen, the organisation should also ask why the account was vulnerable. Did they not have multi-factor authentication? Were credentials reused? Was phishing prevention lacking? If so, were too many privileges granted to the account?
Likewise, if investigators find a vulnerable system has been exploited, they should determine why the system was so vulnerable. The issue could be patch-management lags, incomplete asset inventories, unsupported software, or configuration issues. The updated incident-response guidance urges NIST to learn from incidents and to take lessons learned into broader cybersecurity risk management, not just to “restore and move on. This distinction matters because removing malware or resetting a password may treat the symptoms, not the cause, of a vulnerability that led to the incident.
Recover Systems and Learn from the Investigation
Recovery starts once the organisation has reasonable confidence that it has contained malicious access and addressed the problem. The recovery process shouldn’t rush to get systems back in service; it should be handled carefully. New credentials, more stringent authentication or changed permissions might be needed for affected accounts. Teams can clean, rebuild, or restore compromised systems from known-good backups. In some cases, vulnerable applications may require patches or configuration changes before reconnecting. Post-recovery monitoring should be conducted. Investigators must ensure that the activities of interest have ceased and the same signs of activity are not being seen again in the environment.
NIST SP 800-61 Rev. 3 integrates recovery and lessons learned into broader NIST-initiated cybersecurity risk management processes to minimise future incidents and their impact. A post-incident review can examine what went well and what was challenging. Approval processes may not have been defined, resulting in the organisation discovering incomplete logs, unclear responsibilities, unavailable key contacts, or slow containment decisions. Security controls should also be reviewed to determine whether they need improvement. This could involve stronger multifactor authentication, enhanced monitoring tools, better backups, greater employee awareness, new access authorisation, faster patching, or clearer incident response protocols.
Conclusion
Investigating a Cybersecurity incident follows a structured approach: technical analysis, Evidence Preservation, Communication, Containment, and Organisational Decision-Making. It starts by verifying that the activity is suspicious, needs examination, and requires evidence preservation. Logs, alerts, authentication information, user reports, and system evidence can help determine what happened. The second step is setting up the scope. Investigators must determine which accounts, devices, applications, and information were impacted, and develop a timeline that distinguishes what they know from what they assume.
GET IN TOUCH WITH THE DIGITAL SCHOOL OF MARKETING
Equip yourself with the essential skills to protect digital assets and maintain consumer trust by enrolling in the Cyber Security Course at the Digital School of Marketing. Join us today to become a leader in the dynamic field of cybersecurity.
