Protection of Information Assets: Security Event Management (ISACA CISA)

This course covers the Security Event Management portion of the Protection of Information Assets domain of the CISA (Certified Information Systems Auditor) exam content outline. Combined with the companion domain course on Information Asset Security and Control, this domain accounts for approximately 26% of the total exam. This course focuses on the audit objectives of security awareness training and programs, information system attack methods and techniques, security testing tools and techniques, incident response management, and evidence collection and forensics.

Table of Contents

• Module 1: Auditing Security Monitoring
  • Introduction to Auditing Security Event Management
  • Computer Crime, Attack Categories, and Business Impact
  • Threat Actors, Motivations, and Active vs. Passive Attacks
  • Network and Software Attack Vectors
  • Hardware, Physical, and Human Attack Vectors
  • Malware Categories and Defensive Countermeasures
  • Auditor Responsibilities for Security Testing Programs
  • Conducting Vulnerability Assessments and Penetration Tests
  • Governing and Auditing the Penetration Testing Process
• Module 2: Auditing Security Incident Management
  • Introduction to Auditing Security Incident Management
  • Conducting Security Investigations: Legal Principles and Team Roles
  • Gathering Technical and Non-Technical Evidence
  • Conducting Effective Investigative Interviews
  • Analyzing Investigative Data and Reporting Findings
  • Evidence Handling, Chain of Custody, and Digital Forensics
  • The Value of Security Awareness, Education, and Training
  • Designing Effective Awareness Program Content
  • Reviewing and Measuring Awareness Program Success
• Summary

Module 1: Auditing Security Monitoring

Introduction to Auditing Security Event Management

Every technology, process, and policy in an organization must be monitored to confirm that the technology is functioning correctly, that policies remain current, and that procedures represent a consistent and repeatable way to perform each task. There is no way to know whether technology is working properly, or whether the organization is under attack or already compromised, without actively monitoring systems, networks, and applications.

Auditing security event management is how an organization demonstrates diligence in protecting its business operations and mission through the ongoing monitoring for, and response to, security events. Within the CISA exam content outline, the Protection of Information Assets domain is split into two parts:

1. Information Asset Security and Control – covered in a separate companion course.
2. Security Event Management – the subject of this course, covering system attack methods, security testing, incident response, and forensics.

This domain, taken as a whole, represents about 26% of the CISA examination.

flowchart TB
    A[Protection of Information Assets Domain - 26% of CISA Exam] --> B[Part A: Information Asset Security and Control]
    A --> C[Part B: Security Event Management]
    C --> C1[Security Awareness Training and Programs]
    C --> C2[Information System Attack Methods and Techniques]
    C --> C3[Security Testing Tools and Techniques]
    C --> C4[Incident Response Management]
    C --> C5[Evidence Collection and Forensics]

Computer Crime, Attack Categories, and Business Impact

Auditors need a solid understanding of the types of attacks organizations face, and the methods and techniques used to carry them out. System attacks generally target one or more elements of the CIA triad:

To ensure appropriate and adequate protection against attacks, auditors should assess whether existing controls are accurate, timely, and thorough. Useful inputs to this assessment include:

• Risk assessments and business impact analyses
• Review of previous security incidents and how they were handled
• Follow-up on findings from prior audits that may never have been remediated
• External threat intelligence feeds describing what similar organizations are experiencing
• Comparison against known vulnerability lists (e.g., a “top 20” critical controls list) to confirm the organization has checked for those specific weaknesses

Computer crime is a term that is not always used precisely. Many crimes described as “computer crime” are simply traditional crimes — fraud, abuse, stalking — that now happen to use a computer as the tool, and are typically prosecuted under existing traditional laws rather than requiring new computer-specific statutes. A true computer crime is a crime committed against a computer or network itself — for example, malware designed specifically to cause damage, take over systems, or deprive legitimate users of their rights and abilities. Malware is a contraction of “malicious software” (originally coined as “malfeasant software”), referring to software written with the intent to do harm.

Causal factors contributing to computer crime today:

• Global reach — systems can be attacked from anywhere in the world, with no need for the attacker to be physically present
• No time limits — attacks often begin right as administrators are heading home for the day
• Insecure implementations, unpatched systems, and misconfigurations (studies have shown many organizations run systems more than a year behind on patches, even in supposedly diligent sectors like finance)
• A persistent shortage of skilled security and IT staff able to prevent, detect, and investigate attacks

Impact of computer crime:

• Direct financial loss — fines, remediation and recovery costs, expert/consultant fees, system rebuilding
• Indirect costs — reputational damage, loss of customer confidence, loss of intellectual property (including nation-state and competitor espionage that steals already-completed research), loss of first-to-market competitive advantage
• Regulatory costs — governments continually increase compliance requirements (especially around privacy), which raises the cost of doing business even when compliance itself does not always guarantee that a breach won’t occur
• Cyber-insurance costs — insurers have paid out enormous claims for ransomware and breaches, driving premiums up and, in some cases, making adequate coverage difficult or impossible to obtain

Threat Actors, Motivations, and Active vs. Passive Attacks

Attackers are not inherently “ahead” of defenders — rather, every time defenders close off an easy attack path, attackers are forced to innovate and find a new one. Understanding the threat source helps shape an appropriate defense:

mindmap
  root((Threat Actor Motivations))
    Financial gain
      Steal money or sellable data
      Ransomware-as-a-Service lowers the skill bar
    Ideology
      Political or social cause
      Very hard to deter through cost alone
    Ego
      Prove capability
      Bug bounty / gray-hat curiosity
    Advanced Persistent Threats
      Well funded, patient, organized
      Often shielded by geography or state sponsorship

Key observations about attacker types:

• Attacks motivated by money can sometimes be deterred by making the attack too expensive relative to the reward.
• Attacks motivated by ideology are much harder to deter, since the attacker is not driven by cost-benefit calculations.
• Advanced Persistent Threats (APTs) are well-funded, patient, and often difficult to prosecute because they operate across jurisdictions and may be state-sponsored. Defenders must be “as determined to keep them out as they are desperate to get in” — the attacker’s desperation to succeed must be matched by the defender’s motivation to stop them.
• Tools that once required deep technical skill (custom malware, exploit kits) are now commoditized as Ransomware-as-a-Service, drastically lowering the barrier to entry for unskilled attackers.
• Some attacks originate from insiders — employees acting by accident or out of dissatisfaction — or from customers manipulating input fields (e.g., attempting to alter a displayed price).

Active vs. passive attacks:

flowchart LR
    Attack --> Active[Active Attack]
    Attack --> Passive[Passive Attack]
    Active --> A1[Changes data, disables systems, inserts malware or backdoors]
    Active --> A2[Detectable because something visibly changes]
    Passive --> P1[Eavesdropping, network sniffing, silent data exfiltration]
    Passive --> P2[Designed to avoid detection - may persist for years]

Auditors should confirm that the organization is watching for known/common vulnerabilities (e.g., via a top-20 controls list), that patches are deployed on schedule, that acceptable-use and change-control policies exist and are actually followed (not just documented), and that staff have received adequate training — including staff who inherited a role and system responsibility from someone else without receiving proper training themselves. A recurring theme: many organizations have invested heavily in tools such as SIEM platforms but lack the trained staff to actually analyze and act on the output — an auditor should specifically verify that someone is actively monitoring, not just that a tool was purchased.

Key point: Most compromises of networks and systems result from a combination of factors — misconfiguration, ineffective controls, and lack of monitoring — rather than sheer attacker sophistication.

Network and Software Attack Vectors

Network-based attacks fall into two categories:

1. The network as a conduit — used to compromise devices connected to it.
2. The network itself as the victim — e.g., a denial-of-service attack against network infrastructure.

flowchart TB
    N[Network-Based Attacks] --> N1[Network as Conduit]
    N --> N2[Network as Victim]
    N1 --> N1a[Misrouting of traffic - rogue Wi-Fi APs, fake cell towers]
    N1 --> N1b[Passive sniffing/eavesdropping]
    N1 --> N1c[Active traffic alteration, insertion, or deletion]
    N2 --> N2a[Denial of Service / Distributed Denial of Service]

Auditors reviewing network attack defenses should verify:

• Good network management practices, including up-to-date network diagrams and appropriate network segmentation
• Adequate training for network administrators (an auditor may find highly capable staff who were simply never trained on what to look for)
• Effective change control — poor cabling documentation and mislabeled ports have historically led to serious compromises
• Elimination of single points of failure (e.g., a single firewall as the only defense) through redundancy and load balancing
• Active monitoring of network traffic and logs — one widely cited case involved the loss of 28 million credit card numbers after an attacker exploited an FTP server; the intrusion went unnoticed for 16 months because no one reviewed the logs

Software-based attacks target applications, operating systems, drivers, utilities, and APIs — all of which represent a large attack surface. Key concepts:

Auditor checklist for software-based attack surface reduction:

• Verify robust version-control practices and formal change-control procedures
• Confirm baseline configurations and hardening standards are documented
• Confirm vendor default accounts and passwords have been disabled or changed
• Confirm that security requirements defined during design were actually implemented and tested
• Monitor applications for correct ongoing operation

Hardware, Physical, and Human Attack Vectors

Hardware-based attacks exploit weaknesses in physical computing components:

• Lack of process isolation — architectural flaws that allow one process to read data from another, as seen in the Meltdown and Spectre CPU vulnerabilities, which arose from speed optimizations in hardware chip design
• BIOS/firmware contamination — often possible because systems were not properly patched or maintained
• Physical degradation — accumulated dirt and corrosion causing hardware failure due to inadequate maintenance

Auditor focus areas for hardware attacks:

• Confirm hardware age, patch status, and maintenance records
• Confirm redundancy exists not just at the top level (e.g., two routers) but throughout supporting infrastructure — a documented failure case involved two routers configured for high availability that were both plugged into the same power supply, eliminating the intended redundancy when that power source failed
• Watch for devices sharing a single backplane, which can create a hidden single point of failure
• Consider vendor diversity — relying on a single hardware vendor for all systems means a vendor-wide breach could compromise the entire environment at once

Physical attacks include theft or loss of equipment, power loss, HVAC failure, fire, and water damage (roof leaks, flooding, broken pipes). A guiding principle: physical access control overrides almost every technical control — a 15-character password provides no protection if an attacker can simply walk into the server room and unplug or steal the server.

Illustrative case: an organization had a carbon dioxide fire-suppression system. During testing, a safety key was inserted to prevent accidental triggering. The vendor left without removing the key, and when a real fire occurred shortly afterward, the CO2 system never activated.

Physical audit checklist:

• Confirm uninterruptible power supplies and generators provide adequate backup power
• Confirm fire suppression systems are regularly tested (including checking fire extinguisher charge/inspection dates)
• Confirm preparation for flooding and other natural events
• Confirm equipment is labeled/inventoried and, where appropriate, tracked with asset-tracking technology

Human-based (people) attacks stem from untrained, dissatisfied, or non-compliant staff — but the root cause matters:

flowchart TD
    Q{Are procedures/policies not being followed?} -->|Policy itself is wrong| P1[Auditor should recommend a policy fix]
    Q -->|Management pressured staff to skip steps| P2[This is a management problem, not an employee problem]
    Q -->|Staff are overworked or under-supported| P3[Root cause is burnout, leading to mistakes]

Auditors should always be alert to the risk of fraud or irregular acts during any audit. Statistically, most discovered fraud involves trusted staff, often aged 35–54, who have accumulated elevated privileges over time and whose work is rarely checked because of that trust — making them a high-risk blind spot precisely because controls around them tend to be weakest.

Key access-control principles for reducing human-attack risk:

Auditor checklist for human-based attack surface:

• Confirm employees received training on policies and procedures, and on acceptable use, from day one
• Confirm access rights are re-evaluated regularly — access frequently “accumulates” over years as employees change roles, and stale permissions from previous roles (or from employees who left the organization years earlier) represent unnecessary attack surface
• Confirm timely deprovisioning of access on termination/departure
• Confirm monitoring exists to detect when staff are not performing duties properly, in coordination with HR (including compliance with labor law/union agreements)
• Confirm fair treatment in opportunities and promotions to reduce the risk of a toxic, high-turnover work environment that increases attack surface

Key takeaway: Information systems consist of technical components (hardware, software), process components (change control), and human components. Auditors reduce system-attack risk by evaluating the performance of all of these components together to ensure reliable and secure operations.

Malware Categories and Defensive Countermeasures

A logic flaw or a bug is a developer error — not malware. Malware specifically refers to software written with the intent to do harm.

mindmap
  root((Malware Categories))
    Ransomware
      Encrypts data and demands payment, often in cryptocurrency
      Frequently also exfiltrates personal data
    Spyware
      Covertly monitors and exfiltrates data
    Worm
      Self-propagating, spreads without needing to infect a host file
      Can cause network congestion
    Virus
      Must attach to and infect a host program to spread
    Logic Bomb
      Dormant until a triggering date or event
    Trojan Horse
      Disguised as legitimate or entertaining software
      Hides malicious payload inside

Defensive and response measures:

• Security awareness training — repeatedly reinforcing “don’t open that link” remains one of the most effective controls
• Antivirus/antispam tooling — helpful, but never 100% effective on their own
• Patching — closes the openings malware relies on to gain entry
• Monitoring — unusually high CPU usage or network traffic can indicate compromise
• Backups — must be isolated from the production network; a case was cited where an organization believed it had backups, only to discover during a ransomware event that the backups themselves had also been encrypted because they remained network-connected. A follow-up case described the same organization being infected a second time a year later after being told (and ignoring the advice) that isolated backups were required.
• Network segmentation — limits lateral spread so infection in one segment does not automatically compromise everything else
• Virtualization — a compromised virtual machine can simply be powered down and discarded/rebuilt (though some malware, such as the historical WannaCry attack, attempted to detect whether it was running inside a virtual environment)

Targeted vs. opportunistic attacks: Some attackers are opportunistic (attacking whatever is easiest), while others deliberately target a specific industry or organization — often because that sector is a known “hotspot.” Two frequently targeted sectors are called out specifically:

• Healthcare — spending is concentrated on patient care rather than security; the proliferation of unsecured networked medical devices creates a large, largely unprotected attack surface
• Financial services — targeted because “that’s where the money is”

Preparation strategies discussed:

• A mature incident management program to prevent, detect, and respond effectively
• Threat intelligence feeds describing what is currently affecting similar organizations
• Honeypots — an attractive decoy target placed in the DMZ to observe attacker behavior and gather indicators such as source IP ranges to monitor (not necessarily block)
• Intrusion Detection/Prevention Systems (IDS/IPS), both network-based and host-based, operating alongside firewalls as part of a layered defense model

flowchart LR
    Attacker --> FW[Firewall]
    FW -->|Traffic that gets through| NIDS[Network-Based IDS]
    NIDS --> NIPS[Network-Based IPS]
    NIPS --> Host[Target Host]
    Host --> HIDS[Host-Based IDS]
    HIDS --> HIPS[Host-Based IPS]
    HIPS --> Detected[Detected / Blocked]

Key point: Attacks — and therefore incidents — are inevitable. Organizations must practice due care (the steps taken to try to prevent a problem) and due diligence (verifying those steps are actually working), across technical, managerial, and physical control domains.

Auditor Responsibilities for Security Testing Programs

Auditors must confirm that security testing performed by application developers, network administrators, and system administrators is thorough — covering all aspects of the system. A penetration test of a website only proves whether the website is secure; it says nothing about the rest of the organization if other doors remain open.

Auditor responsibilities regarding testing programs:

• Confirm tests are regularly scheduled and actually performed on schedule (not “we did this a while ago” when it has actually been years)
• Confirm test results are accurate and genuinely look for problems, rather than being superficial
• Confirm results are communicated to management, including whether results represent an improvement over the previous cycle
• Confirm identified issues are actually fixed, not merely documented — “I don’t fix anything by just admitting to it”
• Confirm recommendations are acted upon — money spent on external penetration tests is wasted if findings are never remediated
• Confirm root cause analysis is performed so the underlying problem — not just the symptom — is identified, communicated to management, and (ideally) resolved
• Confirm retesting occurs to verify a proposed fix actually worked, considering business impact, performance impact, security impact, and cost-benefit analysis
• Recognize that auditors act as agents of change — objective reviewers who encourage adoption of solutions, and who should be alert to unrealistic claims about cost savings that don’t match actual costs incurred

Security testing must cover all aspects of the information system:

A cautionary anecdote: an auditor was issued a physical access card previously belonging to a different departed auditor, intended to grant access only to a single office. Testing the card at a separate facility revealed it still granted access to the IT server room — because the card had never been properly zeroed out and reinitialized after reassignment, illustrating the risk of residual, unaudited access rights on physical credentials.

Conducting Vulnerability Assessments and Penetration Tests

A vulnerability assessment is analogous to walking completely around a fortified city looking for every possible weak point — not attempting to break in, but identifying every gap or weakness so it can be prioritized and addressed. Vulnerability assessments are typically based on known vulnerabilities and established methodologies, which — despite differing naming conventions across frameworks — generally follow the same overall process:

flowchart LR
    A[Define Scope] --> B[Gather Information: network diagrams, IP ranges, DNS records]
    B --> C[Reconnaissance: probe target area]
    C --> D[Discover Potential Vulnerabilities]
    D --> E[Detect, Document, and Enumerate Findings]
    E --> F[Analyze: separate real risk from noise]
    F --> G[Report to Management]
    G --> H[Compare Maturity Against Prior Assessments]

Guiding principles: assessors must be as determined and creative as a real attacker rather than simply “running a scan,” and must ensure results reported to management are valid and actionable rather than noisy. Vulnerability assessments can be performed by internal teams, external teams, or both — using both provides more complete coverage.

Penetration testing is the natural next step after a vulnerability assessment: rather than only identifying vulnerabilities, the goal is to actually attempt to exploit them and penetrate the defenses. A pen test typically has a higher success rate when it targets vulnerabilities already surfaced by a prior vulnerability assessment. Benefits of a penetration test include proving whether controls can actually detect an attack in progress, verifying whether intrusion attempts are properly logged, and better preparing administrators to detect and respond to real intrusions.

Hacker classifications relevant to testing:

Auditor concerns regarding penetration testing programs:

• Confirm tests are actually being performed
• Confirm tests are well-designed and would produce an accurate assessment of control effectiveness
• Confirm the resulting report provides valid, actionable recommendations that separate noise from real risk
• Confirm findings are actually followed up on and remediated — a recurring failure mode is that penetration test findings are documented but never acted upon

Governing and Auditing the Penetration Testing Process

The formal process for conducting a penetration test:

flowchart TD
    A[Management Approval of Pen-Test Plan] --> B[Document Scope, Methodology, and Rules of Engagement]
    B --> C[Assign Independent, Technically Qualified Testers]
    C --> D[Execute Test - network, application, physical, social engineering]
    D --> E[Confidential Reporting: Scope + Findings + Business-Aligned Recommendations]
    E --> F{Management Decision}
    F -->|Accept the risk| G[Document risk acceptance in the risk register]
    F -->|Remediate| H[Apply risk-reduction controls]
    H --> I[Retest to Confirm Risk Reduced to Acceptable Level]
    I --> G

Key governance requirements:

• Management approval must always precede testing, including documented scope, methodology, prohibited tools/techniques, and clearly defined rules of engagement (e.g., what to do if testers actually gain access)
• Testers must be independent of the network/system owners and must be able to think creatively beyond simply running an automated tool — including testing social engineering (“what good is a secure password if a person will just give it to you?”) and physical security bypass
• Testers require professional-level technical skill across network design, firewalls/IDS/IPS, routers/switches, Linux command-line administration, and both desktop and server Windows operating systems
• Penetration testing carries real risk — tools used can cause unintended system or process interruption, or even lasting hardware damage requiring component replacement; this underscores the need for formal approval and contingency planning
• Reporting must be confidential, since it discloses exploitable weaknesses; reports must document scope, findings, and — critically — business-aligned recommendations. A recommendation that would technically improve security but cripple normal business operations is not an appropriate recommendation.
• All findings must be captured in a risk register, tracked through to remediation, and validated through retesting once mitigations are applied

Key point: Penetration testing provides valuable insight into the effectiveness of controls and the resilience of systems against real attack attempts.

Module 2: Auditing Security Incident Management

Introduction to Auditing Security Incident Management

Security incident management picks up where security monitoring leaves off. An incident is an adverse event with the potential to disrupt business mission. The core goals of incident management are:

1. Preservation of life, health, and safety
2. Prevention, detection, and effective response to incidents
3. Returning to normal operations as quickly as possible

The auditor’s role in reviewing incident investigations is to confirm that:

• Lessons learned were identified and actually applied
• The effectiveness of the response was formally assessed
• The impact of the incident was accurately measured
• Adequate documentation exists — a clear timeline of what happened, when, and what decisions were made
• The organization’s own incident response plan and procedures were followed, in line with good practice

flowchart LR
    A[Incident Occurs] --> B[Detect]
    B --> C[Respond]
    C --> D[Contain/Eradicate]
    D --> E[Return to Normal Operations]
    E --> F[Document Timeline and Decisions]
    F --> G[Assess Effectiveness / Lessons Learned]
    G --> H[Update Incident Response Plan]

Conducting Security Investigations: Legal Principles and Team Roles

An investigation is triggered when an incident escalates into something more serious — determining what happened, who was involved, and whether the cause was, for example, lack of training or poor equipment maintenance (root-cause analysis). Because it is impossible to know at the outset how serious an incident will ultimately turn out to be, the full incident response process should always be followed, even for incidents that initially appear minor — failing to do so risks contaminating evidence if the matter later proves to be a legal violation.

Investigations can range from a simple administrative investigation of a policy non-compliance (which, at worst, could lead to termination) up to determining potential root causes that, if detected earlier along the attack “kill chain,” might have allowed the incident to be stopped before it escalated.

Core legal/procedural principles for investigations:

• Investigators must never break the law themselves, even while investigating those who did
• Investigators must have clear authority to act — an investigation conducted without HR approval or appropriate policy backing risks violating an individual’s rights
• Approved procedures must be followed, typically under a two-person rule (never a single investigator acting alone)
• Findings must be properly reported — usually internally to management, but potentially externally in serious cases

Investigation team composition:

flowchart TB
    EM[Executive Management / Board Oversight] --> Team
    Team --> Tech[Technical Staff - e.g. database/log searches]
    Team --> ExtExpert[External Certified Experts - e.g. CCTV forensic analysis]
    Team --> Legal[Legal Counsel - liaison with law enforcement, legal privilege]
    Team --> Finance[Finance - for fraud investigations]
    Team --> PhysSec[Physical Security Specialist]
    Team --> HR[Human Resources]
    Team --> PR[Approved Spokesperson - Public Relations]

Public communications guidance:

• A single, trained, always-reachable spokesperson should be designated — it should never be reported that “the company could not be reached for comment”
• Prepared messaging should define exactly what can legally be said, and what must remain confidential
• Because social media accelerates public scrutiny, organizations often need to communicate quickly even before all facts are known — it is more important to be timely than to have every detail confirmed; follow-up updates can be issued as more is learned
• Legal review of public statements helps avoid creating additional liability

Immediate response steps once an incident is reported:

1. Begin documentation immediately, recording when the report was received
2. Secure the scene to prevent contamination or any suspicion of evidence tampering (e.g., seize and preserve a computer in its current state, restrict access)
3. Gather information deliberately and slowly — take photographs, draw diagrams, and record who was present and what was observed, rather than rushing in and disturbing the scene

Gathering Technical and Non-Technical Evidence

Evidence acquisition must be handled carefully to avoid altering evidence in ways that could call its validity into question. Good forensic procedures should be followed even for incidents that initially appear minor, since there may be no second opportunity to gather additional evidence later.

Technical data sources:

Non-technical data sources — people:

People are considered unreliable witnesses: memory can be imprecise, and personal bias (e.g., liking or disliking the subject of the investigation) undermines objectivity. Even so, coworkers and managers should still be interviewed. One cautionary anecdote: when a manager’s first reaction to a complaint was “what is this person complaining about now,” it signaled that the manager’s own bias — not necessarily the employee — might be the underlying issue.

Investigators should also consider expert witnesses for specialized analysis — used because their conclusions carry professional credibility. A cautionary anecdote describes a police officer who testified to conducting a ballistics examination despite never having received ballistics training, undermining the credibility (and admissibility) of that testimony.

Hearsay is testimony about something the witness did not personally observe, but only heard about from someone else — e.g., “Sam told me he saw Albert do this” cannot be offered as direct evidence of what Albert did, only of what Sam said. Hearsay evidence is inherently weak because its reliability depends entirely on the credibility of an intermediary.

Rules of evidence — all gathered evidence should be:

Conducting Effective Investigative Interviews

Interviews are a critical evidence-gathering technique, despite the inherent unreliability, bias, and subjectivity risks of human witnesses discussed earlier. Key interviewing principles:

• Listen more than you talk. A common failure mode is an investigator dominating the conversation, causing the interviewee to simply parrot back what they believe the investigator wants to hear.
• Maintain a non-confrontational and empathetic tone, even when investigating conduct the investigator personally disapproves of — this puts the interviewee at ease enough to speak freely.
• Ask open questions to gather information rather than to express an opinion or lead the interviewee’s thinking.
• Rephrase key questions later in the interview — inconsistent answers to the same underlying question, asked in different ways, can reveal where the truth actually lies.
• Never disclose full case facts to the interviewee, and never conduct interviews one-on-one — an independent observer must always be present.
• Document everything said, as completely as possible.

Who to interview: witnesses, managers, coworkers, other involved parties, and the potential suspect. A well-conducted interview may reveal that the interviewee — including a suspect — discloses important facts without fully realizing they are doing so.

Key takeaway: Interviewing is a skill that even trained professionals frequently execute poorly. Careful listening (rather than talking) and attentiveness to behavioral cues about honesty are central to effective investigative interviews.

Analyzing Investigative Data and Reporting Findings

Once evidence has been gathered, analysis focuses on answering: what happened, how, when, where, and who was involved. Why (motive) is frequently the hardest question to answer, and investigators must guard against false assumptions — assuming a motive without solid evidence risks steering the investigation to the wrong conclusion.

Reporting standards:

• Reports must be factual and unbiased, written for a non-technical audience such as managers and senior managers
• Reports must maintain a clear separation between facts and analysis/opinion — facts and interpretation should never be blended together
• Investigators should avoid absolute statements beyond their qualifications — hedged language (“this might be because…”) is preferable to definitive claims that could later prove embarrassing or incorrect
• Confidentiality must be maintained throughout — being under investigation does not imply guilt, and premature disclosure can damage a person’s career and wellbeing, and may also tip off individuals who could alter evidence
• Only individuals with a legitimate need should receive the final report

Auditor’s core role during investigations:

• Confirm the investigation was conducted legally
• Confirm investigators possessed the necessary skills to conduct the investigation properly
• Confirm the process was fair and thorough, and that the evidence drove the investigation — not a preconceived theory (a recurring failure mode is an investigator ignoring evidence that contradicts their working theory)
• Confirm the final report is complete, including any facts that might complicate the preferred narrative
• Confirm appropriate follow-up recommendations are made

Key takeaway: Investigations carry significant human impact — findings can permanently affect a person’s career and livelihood. Investigators and auditors must exercise care, humility, and rigor, recognizing that a mistaken conclusion has real consequences for real people.

Evidence Handling, Chain of Custody, and Digital Forensics

Evidence is any artifact usable to investigate an incident, whether tangible (a hard drive) or intangible (a verbal statement). Sources of evidence include computer memory (RAM), hard drives and secondary storage, network traffic and logs, mobile devices, and people.

Digital evidence is highly volatile — logs and camera footage can be overwritten within days, systems may be powered down, and simply viewing certain data can alter it. A useful check is the last-access date/time on a file or system, which can indicate patch currency or recent relevance.

Trustworthy evidence is evidence for which the collection method is known and verifiable — direct observation or hands-on collection is preferable to relying entirely on secondhand accounts (a particular challenge with cloud environments, where the organization must trust that the cloud provider’s staff gathered data correctly).

Forensics refers specifically to evidence tied to a possible crime — a step up from a purely administrative matter, potentially involving law enforcement. If law enforcement involvement is likely, the first priority is to step away and secure the scene rather than risk contaminating evidence.

Evidence lifecycle:

sequenceDiagram
    participant Investigator
    participant Evidence
    Investigator->>Evidence: Acquire (image, photograph, capture)
    Investigator->>Evidence: Secure (tamper-evident storage)
    Investigator->>Evidence: Transport (secure chain, no contamination)
    Investigator->>Evidence: Store (restricted access)
    Investigator->>Evidence: Analyze
    Investigator->>Evidence: Report
    Evidence-->>Investigator: Destroy or return to rightful owner

Chain of custody is the unbroken, fully documented record of everyone who handled the evidence, and every action taken on it, across the entire evidence lifecycle. It establishes accountability (who did what) and demonstrates protection from contamination (e.g., placing a hard drive in an anti-static bag sealed with tamper-evident tape, initialed and logged). A break in the chain of custody can render evidence inadmissible — though whether it is actually excluded remains a judge’s decision, and a solid chain of custody is not itself a guarantee of admissibility.

A cautionary anecdote: a police officer transported a seized server by leaning it against the car radio in the trunk. Every time the radio’s transmitter activated, it risked demagnetizing/degaussing the storage media, undermining the evidence’s trustworthiness.

Digital evidence handling best practices:

• Digital evidence is volatile — even observation can alter it, and once altered it typically cannot be restored to its original state
• Use write-protect diodes/write-blockers when imaging a drive so no data can be written back to it
• Copy to clean media that has never previously held data, eliminating any risk of cross-contamination
• Always create two copies: a working copy used for analysis, and a library copy that is never touched again — if the working copy becomes contaminated, a fresh working copy can be created from the library copy
• Perform imaging at the bit level to capture everything on the storage media
• Take photographs throughout the process

Key point: Damaged evidence generally cannot be repaired. It is not realistic to claim evidence will never be changed during an investigation — for example, investigating a powered-on desktop necessarily changes its state. The goal instead is to follow good practices that minimize change, document precisely what was done and why, always have a second person present as an independent observer, and thoroughly document everything — since investigations can span months or years, and memory alone cannot be relied upon.

The Value of Security Awareness, Education, and Training

Security awareness, education, and training is considered one of the most effective controls available. Awareness creates accountability: once a person knows the rules, they are accountable for following them.

According to NIST Special Publication 800-50, even a small amount of IT security awareness and training can meaningfully improve an organization’s IT security posture and vigilance. Critically, awareness is not training — its purpose is simply to focus attention on security and reinforce desired behavior: what behaviors, policies, and procedures are expected, and what the penalties are for non-compliance.

Management commitment is essential. As reflected in ISO 27001, management must demonstrate visible leadership and commitment — following the same policies they expect of everyone else (e.g., if ID badges must be visibly worn at all times, managers must wear theirs too, setting the example).

Auditing a security awareness program should assess:

• Employees’ current level of security knowledge, via surveys and interviews
• Management’s views on which topics are most important to emphasize
• Historical attendance at awareness sessions
• Patterns in security events/incidents, which may highlight areas needing more awareness focus (e.g., using a real ransomware event as a teaching moment, framed not to assign blame but to demonstrate that security and audit functions are actively engaged in protecting the organization)

Organizations can also build a security champions program — local staff embedded in departments like finance and sales who help promote, support, and monitor the security program and answer day-to-day questions from their peers, and who can advise on how best to deliver awareness content in a way that fits their department’s culture.

Designing Effective Awareness Program Content

Effective awareness content is:

• Tailored to the audience — the message for managers differs from the message for IT administrators, which differs again from the message for end users or customers
• Focused on a clear, memorable key message — if a participant is asked what they took away from a session, they should be able to answer clearly
• Aligned with organizational culture, since different work groups have different cultures and communication styles
• Delivered starting from an employee’s first day, and refreshed continuously — a single onboarding mention is not sufficient
• Varied in format — posters are effective for roughly the first few days before becoming “wallpaper” that no one notices; delivery methods must be rotated

Topics typically covered:

• Malware types and defenses
• Security policies and procedures, and acceptable use
• Good password selection practices, presented in a way that makes secure behavior possible, not burdensome
• Emerging technologies, threats, and trends — including AI (benefits, risks, and things to watch for), blockchain, and cryptocurrency
• Ransomware, and the very common and highly effective attack technique of social engineering — manipulating a person into taking an action they should not, through intimidation, name-dropping (“your boss told me to ask you”), technical phishing, or appeals for help. The single most important awareness message: “If you follow the procedure, you will never get in trouble” — this empowers employees to refuse a social-engineering request without fear of repercussions, since there is almost no purely technical control that defends against it.

Delivery methods:

Reviewing and Measuring Awareness Program Success

Like any control, the awareness program itself must be reviewed and measured. Evaluation methods include:

• Surveys and post-session evaluations
• Staff interviews and focus groups discussing session topics
• Direct observation of behavior change
• Status reports tracking attendance by work group

Indicators of a successful program:

• The program has adequate budget
• Management visibly follows the same rules and does not bypass controls — including attending sessions themselves
• Strong attendance across work groups
• The program owner demonstrates genuine passion and motivation, which tends to be contagious

Per NIST SP 800-50, an important and counter-intuitive evaluation point: while improved security behavior can reduce the number of actual incidents/violations, the number of reported potential incidents may actually increase as a direct result of heightened staff vigilance — this should be read as a positive indicator of program success, not a sign of failure.

Awareness training extends beyond employees — it should also be extended to vendors, contractors visiting the site, and customers (e.g., helping customers avoid becoming victims of multi-factor authentication bypass scams), and everyone accessing company premises should understand applicable acceptable-use policies.

Key takeaway: As auditors, we are accountable for emphasizing the value of security awareness programs and confirming they deliver measurable, positive benefit — recognizing that security and good practice is everybody’s job.

Summary

This domain — Protection of Information Assets — is split into two parts: Information Asset Security and Control, and Security Event Management (the focus of this course). Together, this domain represents about 26% of the CISA examination. The auditor’s core focus in Security Event Management is verifying how well the organization detects, manages, and learns from security events.

Golden rules for the exam:

• Security awareness training is generally the best available security control — when in doubt about a recommended remediation, security awareness training is usually a strong candidate answer.
• System attacks may be internal or external, and may be intentional or unintentional — never assume all threats are external or malicious.
• Monitoring is essential to detect incidents promptly; tools alone (e.g., a SIEM platform) are not sufficient without trained staff actively watching them.
• A vulnerability assessment identifies weaknesses; a penetration test attempts to actually exploit them — know the distinction, and remember that penetration testing covers far more than web applications (it includes people, physical security, and social engineering).
• Investigators must never exceed their authority, and must remain thorough, unbiased, and complete throughout an investigation.
• Chain of custody and the rules of evidence (relevant, timely, complete, legally admissible) govern whether evidence can ultimately be used.

Quick-Reference Table: Security Event Management Domain

CISA Exam Study Checklist

• Can explain the CIA triad impact of different categories of system attacks
• Can distinguish active vs. passive attacks, and threat-actor motivations (money, ideology, ego, APT)
• Can describe network, software, hardware, physical, and human attack vectors and applicable auditor checks
• Can differentiate malware types: ransomware, spyware, worm, virus, logic bomb, trojan horse
• Understands least privilege, need-to-know, and separation of duties as human-attack mitigations
• Can describe the vulnerability assessment methodology (scope, gather, recon, discover, document, analyze, report)
• Can distinguish white hat, gray hat, and black hat, and blind vs. double-blind testing
• Understands the required governance steps for a penetration test (approval, scope, rules of engagement, reporting, remediation, retest)
• Can describe the incident investigation team composition and the role of an approved spokesperson
• Understands technical vs. non-technical evidence sources, hearsay, and the rules of evidence (relevant, timely, complete, admissible)
• Can describe effective interview technique (listen, non-confrontational, always use an observer)
• Understands the evidence lifecycle and chain of custody, and why digital evidence is volatile
• Understands the distinction between awareness, training, and education, and why increased incident reporting can indicate awareness success
• Understands due care vs. due diligence

Search Terms

protection · information · assets · security · event · management · isaca · cisa · governance · risk · compliance · networking · systems · auditing · attack · awareness · conducting · categories · effective · evidence · incident · investigative · penetration · program