Module 5: Deliverable and Integration

Semester Exam Notes | 16-Mark Answer Format

Introduction
The deliverable and integration phase is the final and most critical stage of the
cybersecurity testing lifecycle. After all reconnaissance, scanning, and exploitation is
complete, this phase transforms raw test results into actionable security
improvements. Think of it as the "so what now?" phase — all the findings mean
nothing unless they are properly documented, presented, and acted upon.
This phase has four main goals: (1) Create a formal report documenting everything
found during testing. (2) Present the findings clearly to all stakeholders. (3)
Recommend specific fixes and security improvements. (4) Plan for long-term
defense and monitoring to prevent future breaches.
Without a strong deliverable and integration plan, even the best penetration test
produces zero improvement in actual security — the organization simply would not
know what is broken or how to fix it.
1. The Deliverable
Definition
The deliverable is the formal, written output of an entire cybersecurity engagement. It
is the complete document that a penetration tester or security consultant hands over
to the client after finishing the assessment. It is not just a simple list of problems — it
is a structured, professional account of what was tested, what was found, how it was
discovered, and most importantly, what needs to be done to fix it.
In simple terms: the deliverable answers the question — "What happened during our
security test, and what must we do now?"

Key Components of the Deliverable

Component What It Includes Real-World Example

Overview of testing scope, Tested web application
Summary of objectives, duration, and resilience against SQL
Engagement methodologies used during the injection and cross-site
engagement scripting (XSS)
Detailed descriptions of every Unencrypted credentials
discovered vulnerability — transmitted in plaintext over
Findings
including severity, impact, and HTTP discovered during
proof of exploitation network traffic analysis
Implement HTTPS (TLS 1.3),
Specific, actionable, and
Recommendation enforce HSTS headers, and
prioritized steps to mitigate each
s disable weak cipher suites on
identified risk
the web server
Wireshark PCAP file showing
Screenshots, packet captures,
plaintext credentials; Burp
Supporting Data tool outputs, and logs that serve
Suite screenshot showing
as evidence for every finding
SQL injection response

Detailed Explanation of Each Component

Summary of Engagement: This opening section tells the reader exactly what was
tested and why. It covers the scope (which systems and networks were included),
the objectives (what the testers were trying to achieve), the authorization details
(proof that testing was legally approved), the testing methodology used (black box,
grey box, or white box), and the timeline of the engagement. This context is essential
— without it, findings cannot be properly interpreted.
Findings: The findings section is the heart of the deliverable. Every single
vulnerability that was discovered must be documented here in detail. Each finding
should include the vulnerability name, the affected system or component, the CVSS
severity score, a clear description of the flaw, step-by-step proof of how it was
exploited, the potential business impact if left unpatched, and a specific
recommendation for fixing it.
Recommendations: For every finding, there must be a concrete recommendation.
These cannot be vague — they must be actionable. Instead of writing "improve
security," write "Update Apache HTTP Server to version 2.4.57 to patch CVE-2023-
XXXX" or "Enable multi-factor authentication for all administrator accounts using
Google Authenticator or Microsoft Authenticator." Recommendations should be
sorted by severity so that the most dangerous issues are fixed first.
Supporting Data: Evidence is non-negotiable. Without supporting data, the client
has no reason to trust the findings, and developers cannot reproduce or verify the
issue. Supporting data includes: screenshots of exploit output, Nmap/Nessus scan
reports, Burp Suite request/response captures, Metasploit session logs, and
Wireshark packet captures. This data also protects the tester legally by proving the
test was conducted professionally.

EXAM TIP In a 16-mark answer: define "deliverable" first (2 marks), then

explain ALL 4 components with examples (3 marks each = 12 marks), then
conclude with 2 lines about its importance (2 marks). Examiners specifically
look for real examples like Wireshark, Burp Suite, and CVSS scores.
2. The Document
Purpose
The document — also known as the Penetration Testing Report — is the formal
written report shared with all stakeholders after the engagement. Its core purpose is
to ensure that every party involved, regardless of their technical background, can
understand what was found during testing, why it poses a risk, and what actions are
needed in response.
A well-crafted document bridges the communication gap between the technical world
and the business world. The security engineer needs exploit details and CVE
numbers. The CEO needs to understand financial risk and regulatory exposure. The
document must serve both audiences effectively.

Structure of the Document

Section Purpose Target Audience

Identifies the report — project
Title Page name, client, tester, date, and All stakeholders
confidentiality classification
Allows quick navigation to any
Table of Contents section of the report using page All stakeholders
references
A non-technical, high-level
Executive overview of findings, risk levels,
Management, C-Suite, Board
Summary and top priority actions written in
business language
In-depth descriptions of
IT Team, Developers, Security
Technical Details vulnerabilities, testing steps, tools
Engineers
used, and proof of exploitation
A prioritized list of fixes organized
Remediation IT Team, Project Managers,
by severity level (Critical, High,
Plans Management
Medium, Low)
Raw logs, full scan outputs,
Appendices screenshots, and supporting Auditors, Security Engineers
evidence for all findings

Detailed Explanation of Each Section

Title Page: The cover of the report. Must include: the engagement name and type
(e.g., "External Penetration Test — Q3 2024"), the client organization name, the
testing firm and lead tester name, the report date, the classification level (e.g.,
"CONFIDENTIAL — Restricted Distribution"), and a statement confirming the test
was authorized. This creates a professional impression and establishes legal
context.
Table of Contents: A structured list of all sections and their page numbers. In
digital reports, these should be hyperlinked for easy navigation. For large reports
with 20-50 findings, this is essential for usability. It shows the reader exactly how the
report is organized before they begin reading.
Executive Summary: This is the most-read section by senior leadership. It should
be written in plain English with zero technical jargon. Contents: overall security
posture assessment (Poor / Fair / Good), total number of findings by severity, the 3-5
most critical issues and their potential business impact (e.g., "A critical vulnerability
in the payment portal could expose 500,000 customer records"), and top priority
recommended actions. Think of it as a one-page business memo summarizing the
entire test.
Technical Details: Written for engineers and developers. Includes: a detailed
methodology section explaining each testing phase (Recon, Enumeration,
Exploitation, Post-Exploitation), individual vulnerability write-ups with CVE references
and CVSS scores, exact tool commands used (e.g., "nmap -sV -sC -p-
[Link]"), and step-by-step reproduction steps so developers can verify the
issue.
Remediation Plans: Each vulnerability should have a concrete, specific fix
recommendation. Group recommendations by severity: Critical/High fixes should
have immediate deadlines (24-48 hours or 1 week), while Medium/Low can be
addressed in the next scheduled patch cycle. Include both short-term workarounds
(e.g., "disable the vulnerable feature") and long-term permanent fixes (e.g., "upgrade
to patched version").
Appendices: Everything goes here. Raw Nmap output files, full Nessus scan
reports, Burp Suite project files, Metasploit session transcripts, and Wireshark
captures. Keeping these in the appendix keeps the main report clean and readable
while still providing all evidence needed for verification and compliance audits.

EXAM TIP Memorize the 6 sections with this mnemonic: "Totally Trained
Experts Teach Remediation Always" (Title, TOC, Executive, Technical,
Remediation, Appendices). The Executive Summary is the most common
exam focus — always emphasize it is non-technical and aimed at
management.
3. Overall Structure
Purpose
The overall structure of a cybersecurity report ensures that the document is logically
organized, progressively detailed, and useful to people with vastly different levels of
technical knowledge. A well-structured report enables stakeholders to quickly locate
the information they need and take the right actions at the right time.

Detailed Sample Structure

• Introduction: States the goals of the engagement, the agreed-upon scope
(exactly which systems and IP ranges were included), any limitations or
exclusions (what was NOT tested), the testing window (dates and times), and
proof of authorization. This section prevents "scope creep" disputes and
ensures the client understands what was and was not covered.
• Methodology: Explains the exact approach used during testing, broken into
phases. Phase 1 — Reconnaissance: passive and active information
gathering (OSINT, Shodan, Nmap). Phase 2 — Enumeration: identifying open
ports, running services, OS fingerprinting, user accounts. Phase 3 —
Vulnerability Assessment: scanning for known CVEs using tools like Nessus,
OpenVAS. Phase 4 — Exploitation: attempting to exploit confirmed
vulnerabilities using Metasploit, manual exploits. Phase 5 — Post-
Exploitation: assessing how far an attacker could go after initial access
(privilege escalation, lateral movement, data exfiltration).
• Findings: All discovered vulnerabilities listed and categorized by severity.
Each finding entry includes: Vulnerability Name, Affected Asset, CVSS Score,
Description, Evidence (screenshots/logs), Business Impact, and
Recommendation.
• Recommendations: A master list of all recommended fixes, prioritized by
severity, with responsible owners assigned and target completion dates.
• Conclusion: A final summary of the engagement outcome, overall risk
rating, and confirmed next steps such as scheduling a retest after fixes are
applied.

Vulnerability Severity Classification Table

CVSS Action
Severity Description Example
Score Timeline
Directly exploitable; Remote Code
causes complete system Execution (RCE) on Fix within 24-48
Critical 9.0 - 10.0
compromise or large- a public-facing web hours
scale data breach server
High 7.0 - 8.9 Serious issues SQL Injection in a Fix within 1
 CVSS Action
Severity Description Example
Score Timeline
compromising key
systems or business
customer login portal week
processes; harder to
exploit than Critical
Moderate risks requiring Default admin
Fix within 1
Medium 4.0 - 6.9 attention but not credentials on an
month
immediately catastrophic internal server
Minor risks or
Verbose error
misconfigurations that Fix in next
Low 0.1 - 3.9 messages revealing
pose little immediate patch cycle
server version info
threat

EXAM TIP Know ALL 4 severity levels with their CVSS score ranges and
examples. CVSS = Common Vulnerability Scoring System (0-10 scale). The
5-phase methodology (Recon, Enum, Vulnerability Assessment, Exploitation,
Post-Exploit) is frequently tested as a short-answer question.
4. Aligning Findings
Purpose
Aligning findings means connecting the technical vulnerabilities discovered during
testing to real business concerns, compliance obligations, and organizational risk
priorities. A raw list of CVEs means little to a hospital administrator. But telling them
"this vulnerability could expose 10,000 patient records and violate HIPAA, resulting
in fines up to $1.9 million" — that gets immediate attention.
Different organizations have different risk profiles. A hospital prioritizes patient data.
A bank prioritizes transaction security. A retailer prioritizes payment card data.
Alignment ensures the security report is relevant and actionable for that specific
organization's context.

Step 1 — Risk Prioritization

Not all vulnerabilities are equally dangerous for all organizations. The process: first,
understand which systems and data assets are most critical to the business. Then
rank vulnerabilities by their potential impact on those critical assets. Use a Risk
Score combining likelihood of exploitation and impact on the business.
Example: A critical SQL injection vulnerability in the public payment portal ranks
higher than the same severity vulnerability in an isolated development server —
because the payment portal processes real customer financial data while the dev
server does not.

Step 2 — Compliance Mapping

Many organizations are legally required to meet specific security standards. Mapping
findings to regulations makes the report far more compelling for legal, audit, and
executive teams.

Key Penalty for

Regulation / Who Must
What It Covers Non-
Framework Follow It
Compliance
Protection of personal Any organization Up to 4% of
GDPR (General
data of EU citizens; handling EU global annual
Data Protection
breach notification within citizen data revenue or EUR
Regulation)
72 hours globally 20 million
Security of payment card All organizations
Fines, increased
PCI DSS (Payment transactions and that process,
transaction fees,
Card Industry Data cardholder data storage, store, or transmit
or loss of card
Security Standard) processing, and credit/debit card
processing rights
transmission data
HIPAA (Health Protection of patient Healthcare Civil penalties up
Insurance health information (PHI) providers, to USD 1.9
 Key Penalty for
Regulation / Who Must
What It Covers Non-
Framework Follow It
Compliance
insurers, and million per
Portability and and electronic health their business violation
Accountability Act) records (EHR) associates category per
(primarily US) year
Any organization
Information security seeking formal Loss of
management best security certification;
ISO 27001
practices and framework certification; often competitive
for building an ISMS required by disadvantage
enterprise clients

Step 3 — Stakeholder Relevance

After prioritizing and mapping to compliance, tailor the presentation of findings to
each audience. Show each stakeholder only what is most relevant to their role and
responsibilities.
• For IT Team: Full technical vulnerability details, CVE references, exploit proof,
and step-by-step remediation instructions.
• For Management: Business impact in financial and reputational terms,
regulatory penalties at risk, and priority action list with resource estimates.
• For Auditors: Evidence of control failures mapped to specific regulatory
clauses, documentation of findings, and remediation evidence from prior tests.

Why Alignment Matters

• Ensures limited organizational resources (budget, people, time) are focused
on the most impactful issues first.
• Helps security teams justify cybersecurity investments to management and
boards using business language.
• Makes reports directly useful for compliance audits — regulators want to see
how findings map to their requirements.
• Prevents the "so what?" problem — where technically accurate findings are
dismissed because their business impact was never explained.

EXAM TIP Always state the 3 steps: Risk Prioritization, Compliance

Mapping, Stakeholder Relevance. GDPR (72-hour notification, 4% revenue
fine), PCI DSS, and HIPAA are very frequently tested. Know at least one
specific penalty figure for GDPR. Risk Score = Likelihood x Impact.
5. Presentation Integrating the Results
Purpose
Once the report is written, the findings must be formally presented to stakeholders.
This step is critical because a technically perfect written report can still fail to drive
action if it is presented poorly. The presentation phase is about communicating
results in a way that is clear, tailored to the audience, and motivating enough to
cause the organization to act.

Element 1 — Tailored Presentations

The single biggest mistake is using the same presentation for all audiences. A CEO
presentation should never look like a developer briefing. Every audience needs a
different message, level of technical detail, and call to action.

Their Core
Audience What to Present Language Style
Concern
Risk level summary,
Business risk, Plain business
potential cost of breach,
Executive / C- regulatory fines, language — avoid
comparison of fix cost vs.
Suite / Board financial loss, brand all technical
breach cost, compliance
reputation jargon
status dashboard
Technical root
CVE details, tool outputs, Full technical
causes, exploit
IT / Security exploit proof, patch detail — use
mechanics, how to
Team versions, configuration fix proper security
reproduce and fix
steps terminology
issues
Regulatory Compliance mapping
Regulatory and
Auditors / alignment, evidence table, evidence
governance
Compliance quality, control gap documentation, prior
language
analysis finding retest results
Project
Project / Timeline, resources Prioritized remediation management
Operations needed, who does plan with owners and language —
Managers what deadlines assigned timelines and
owners

Element 2 — Visualization Tools

Visual data is understood faster and remembered longer than text. For executive
presentations especially, charts and diagrams are essential.
• Pie Chart: Vulnerability distribution by severity level — instantly shows what
percentage of findings are Critical, High, Medium, and Low.
 • Bar Graph: Number of vulnerabilities per system or department — shows
which areas of the organization carry the highest risk.
• Risk Matrix (Heatmap): A 2D grid plotting Likelihood vs. Impact — helps
prioritize remediation visually.
• Timeline: Shows when each testing phase was conducted and when fixes are
expected to be completed.
• Trend Chart: If the organization has been tested before, a trend line showing
whether security posture is improving or worsening over time.

Element 3 — Interactive Q&A Session

After presenting findings, always schedule time for a structured Q&A. This is
important because: management may dispute risk ratings and need clarification,
technical staff may need more detail on specific exploits, and stakeholders build trust
in the findings when they can ask questions directly. The presenter should: welcome
all questions, be prepared to explain technical findings in simpler terms, and follow
up in writing for any questions they cannot answer on the spot.

Best Practices for Presentation

• Never share sensitive exploit details in a group setting — distribute full
technical details only to authorized recipients.
• Keep executive presentations to 10-15 slides maximum, focused on the top 5-
10 most critical findings.
• Always end every presentation with a concrete "Next Steps" slide showing
who does what and by when.
• Practice the presentation beforehand — confidence and clarity are as
important as content quality.

EXAM TIP Tailored presentations is the most important concept here —

always explain the different needs of executives versus IT teams.
Visualization types (pie chart, risk matrix, heatmap) often appear as fill-in-the-
blank exam questions. The Q&A builds stakeholder trust and buy-in —
mention this explicitly.
6. Integration Summary
Definition
The integration summary is the section that explains exactly how the findings and
recommendations from the security test will be incorporated into the organization's
actual security operations and strategy. It bridges the gap between "here are the
problems" and "here is our plan to fix them — right now and over time."
The integration summary answers: What gets fixed immediately? What gets fixed
over the next months? How do we confirm everything was actually fixed? Who is
responsible for what?

Components of the Integration Summary

Component Time Frame Description Example Actions

Disable exposed
management ports
(23, 3389); enforce
Quick, high-priority actions
MFA on all admin
Short-Term Immediate (0 to to immediately reduce risk
accounts; apply
Fixes 30 days) from the most critical
emergency patches
vulnerabilities
for Critical CVEs;
change all default
credentials
Implement quarterly
vulnerability
Strategic, structural assessments;
changes to prevent similar deploy a SIEM
Ongoing (1 to
Long-Term vulnerabilities from system; design and
12 months and
Plans recurring and to build a enforce network
beyond)
stronger overall security segmentation; run
posture mandatory security
awareness training
annually
Conduct targeted
Follow-up testing to confirm
retest of all Critical
that fixes were correctly
and High findings
After each fix implemented and no new
Verification within 30 days of
(retest cycle) vulnerabilities were
patch deployment;
introduced during
document retest
remediation
results

Integration Process — Flowchart

 STEP 1 — Review All Findings and Prioritize by Severity
and Business Impact

|
V
STEP 2 — Assign Owners: Who Is Responsible for Fixing
Each Issue?

|
V
STEP 3 — Implement Short-Term Fixes (Patch Critical and
High vulnerabilities immediately)

|
V
STEP 4 — Implement Long-Term Fixes (Policy changes,
architecture improvements, training)

|
V
STEP 5 — Retest and Verify All Fixes (Confirm patches
were correctly applied)

|
V
STEP 6 — Update Security Strategy and Document All
Lessons Learned

Detailed Explanation
Short-Term Fixes: These are emergency actions taken immediately after receiving
the report. The goal is to stop active risk as fast as possible. Examples: block known
malicious IP addresses in the firewall, disable exposed Remote Desktop Protocol
(RDP) port 3389, reset all accounts that may have been compromised, and apply
emergency patches for Critical CVEs. These are tactical, reactive fixes.
Long-Term Plans: These are strategic investments in security infrastructure and
culture. Examples: deploying a Security Operations Center (SOC) with 24/7
monitoring, implementing Zero Trust Architecture (never trust, always verify),
restructuring network segmentation to limit lateral movement, and conducting annual
security awareness training programs. These changes are preventive and proactive.
Verification: A fix that has not been verified is useless. After critical fixes are
applied, the security team must retest to confirm: the original vulnerability is fully
closed, the fix did not introduce new vulnerabilities, and security controls are working
as intended. Verification results should be documented and included as an
addendum to the original report.
 EXAM TIP The 3 components — Short-Term, Long-Term, Verification —
will almost certainly appear in your exam. The 6-step flowchart is perfect for
exam diagrams. Key definition: "Integration = taking findings off paper and
turning them into real, verified security improvements in the organization."
7. Mitigation
Definition
Mitigation refers to the concrete actions taken to reduce, minimize, or completely
eliminate the risks posed by identified vulnerabilities. It is the practical execution of
the recommendations from the deliverable. Mitigation does not always mean 100%
elimination — sometimes it means reducing a risk to an acceptable level while a
permanent fix is being developed.
A useful analogy: mitigation is like treating an injury. You may not be able to prevent
every future injury, but you can clean the wound, apply a bandage, and take
antibiotics to prevent infection from getting worse. Similarly, mitigation reduces the
likelihood and impact of a successful cyberattack.

Steps in Mitigation

Mitigation Step Description Tools / Examples

Identify and apply software updates Windows Update, WSUS,
to fix known vulnerabilities. The Ansible, Chef. Example:
1. Patch most direct and effective form of Patch MS17-010
Management mitigation — unpatched software is (EternalBlue) to prevent
the #1 attack vector for most WannaCry-style
organizations. ransomware attacks.
CIS Benchmarks, DISA
Configure systems to their most
STIGs. Example: Disable
secure state by removing all
2. System Telnet and enable SSH
unnecessary features, services,
Hardening only; remove guest
accounts, and access points that
accounts; disable AutoRun;
increase the attack surface.
enable host-based firewall.
Enforce the principle of least RBAC (Role-Based Access
privilege (PoLP) — every user, Control), PAM (Privileged
process, and system should only Access Management), MFA.
3. Access Control
have the minimum permissions Example: Marketing team
needed to perform their specific cannot access the financial
function. database.
IDS/IPS (Snort, Suricata),
Deploy real-time monitoring systems SIEM (Splunk, QRadar),
to detect suspicious activity, trigger EDR (CrowdStrike,
4. Monitoring
alerts, and enable rapid response SentinelOne). Example:
before major damage is done. Alert when 10+ failed logins
occur in 60 seconds.

Detailed Explanation of Each Step

1. Patch Management: Organizations must have a formal, documented patch
management process. Key steps: (a) Maintain a complete inventory of all software
and systems in use. (b) Subscribe to CVE feeds and vendor security advisories to
learn about new vulnerabilities. (c) Test patches in a non-production staging
environment first. (d) Deploy patches in priority order — Critical and High severity
first. (e) Document all patch activities for compliance audits. The WannaCry
ransomware attack of 2017 infected over 200,000 systems in 150 countries because
organizations failed to apply Microsoft's MS17-010 patch that had been available for
2 months.
2. System Hardening: System hardening means removing everything that is not
necessary for the system's core function. Key hardening actions: disable all unused
network ports and services (check with "netstat -an"), remove all default factory
accounts and change default passwords, apply operating system security baselines
(CIS Benchmarks provide detailed checklists for every OS), enable the host-based
firewall and configure strict inbound/outbound rules, and disable features like
PowerShell Remoting, WMI, and AutoRun unless explicitly needed. A hardened
system gives an attacker far fewer options to exploit, dramatically reducing risk even
before patches are applied.
3. Access Control: The principle of least privilege ensures that even if an attacker
compromises one account, they face significant barriers to spreading through the
network. Key access control measures: implement RBAC to assign permissions
based on job roles, not individuals; deploy MFA for all privileged accounts and
remote access; use PAM tools to manage and audit privileged account usage;
conduct quarterly access reviews to identify and revoke stale permissions;
implement just-in-time (JIT) access for administrative tasks instead of permanent
elevated permissions. The AAA framework (Authentication, Authorization,
Accounting) underpins all access control.
4. Monitoring: Real-time monitoring transforms the organization from reactive to
proactive. Key monitoring capabilities: IDS (Intrusion Detection System) analyzes
network traffic for known attack signatures; IPS (Intrusion Prevention System) goes
further and actively blocks detected attacks; SIEM aggregates logs from all systems
and correlates events to detect complex, multi-stage attacks; EDR (Endpoint
Detection and Response) monitors individual devices for malicious processes, file
changes, and network connections. The goal: detect and respond to threats in
minutes rather than months. The average time to detect a breach without proper
monitoring is 197 days (IBM Cost of a Data Breach Report).

EXAM TIP The 4 steps (Patch Management, System Hardening, Access

Control, Monitoring) must be memorized with examples. WannaCry /
EternalBlue / MS17-010 is an excellent patch management example. "Least
Privilege" and "AAA Framework" are key exam terms. CIS Benchmarks for
hardening is frequently asked.
8. Defense Planning
Definition
Defense planning is the strategic, forward-looking process of building a
comprehensive, sustainable security program that prevents, detects, and responds
to future cyber threats. While mitigation addresses specific current vulnerabilities
(reactive), defense planning builds the overall security infrastructure that protects the
organization against the next attack — and the one after that (proactive).
Defense planning is about asking: "Now that we know how we can be attacked —
how do we build systems and processes so that the next attacker fails?" It moves the
organization from security by accident to security by design.

Step 1 — Incident Response Plans (IRP)

An Incident Response Plan is a written, tested document that defines exactly what
the organization does when a security incident occurs. Without a pre-defined plan,
teams panic, communicate poorly, and make mistakes under pressure — all of which
make breaches worse and more expensive.
Key contents of an IRP: the Incident Response Team composition (who is on the
team and their roles), communication protocols (who calls whom, how incidents are
escalated), predefined playbooks for specific incident types (ransomware, data
breach, insider threat), legal and regulatory notification requirements (e.g., GDPR
72-hour reporting), and evidence preservation procedures for forensic investigation.
IRPs must be tested through tabletop exercises (simulated discussions) and red
team exercises (simulated actual attacks) at least annually.

Step 2 — Continuous Monitoring

Continuous monitoring means the organization is watching its environment for
threats 24 hours a day, 7 days a week, 365 days a year. The primary tool for this is a
SIEM — Security Information and Event Management system.

SIEM Capability What It Does Why It Matters for Defense

Gathers security logs from all
Centralizes all event data in
sources: firewalls, servers,
Log Collection one place — nothing is
endpoints, cloud services,
missed
applications
Detects complex multi-stage
Identifies relationships and
attacks like Advanced
Event Correlation patterns across events from
Persistent Threats (APTs)
multiple different systems
that span days or weeks
Real-Time Alerting Immediately notifies the security Enables response in
team when suspicious patterns minutes instead of months
 SIEM Capability What It Does Why It Matters for Defense
— dramatically reduces
are detected
breach impact
Provides visual overview of the Helps security teams
Dashboards &
overall security status and key prioritize threats and track
Reporting
metrics incident resolution
Automatically generates Simplifies audits for PCI
Compliance
compliance reports required by DSS, HIPAA, GDPR, ISO
Reporting
regulators 27001

Popular SIEM tools: Splunk, IBM QRadar, Microsoft Sentinel, ArcSight, and the
open-source ELK Stack (Elasticsearch, Logstash, Kibana).

Step 3 — Regular Testing

A one-time penetration test is a snapshot in time. Defense planning requires
ongoing, regular testing to continuously identify new vulnerabilities as the
environment changes.
• Annual or bi-annual full penetration tests covering the entire scope.
• Quarterly vulnerability scans using tools like Nessus, Qualys, or Rapid7
InsightVM.
• Red Team / Blue Team exercises: a dedicated attacker team (Red) versus the
defenders (Blue) — simulates real Advanced Persistent Threat (APT)
scenarios.
• Phishing simulation campaigns to regularly test employee security awareness
and resilience.
• Bug bounty programs: invite external security researchers to find
vulnerabilities and reward them — a crowdsourced security testing approach.

Additional Defense Strategies

• Zero Trust Architecture: "Never trust, always verify." Every user and device
must authenticate and be authorized for every request — even if they are
already inside the corporate network. Eliminates the dangerous assumption
that everything inside the firewall is safe.
• Network Segmentation: Divide the network into isolated zones so that a
breach in one zone cannot automatically spread to the rest. Critical systems
should be in their own isolated segment with strict access controls.
• Security Awareness Training: Humans are consistently the weakest link in
any security chain. Regular training on phishing recognition, social
engineering tactics, password hygiene, and safe browsing reduces human-
error incidents significantly.
• Backup and Disaster Recovery: Maintain regular, encrypted, and offline
backups of all critical data. Test backups regularly. This enables recovery
from ransomware attacks without paying the ransom.
 EXAM TIP Defense Planning = IRP + Continuous Monitoring (SIEM) +
Regular Testing. Know what SIEM stands for and its 5 capabilities. Name
specific SIEM tools (Splunk, QRadar, Sentinel). Zero Trust Architecture is a
major modern exam topic. IRP tabletop exercises are frequently tested.
9. Incident Management
Definition
Incident management is the structured, documented process for identifying,
managing, analyzing, and resolving security incidents in a coordinated and effective
manner. A security incident is any event that threatens the confidentiality
(unauthorized data access), integrity (unauthorized data modification), or availability
(denial of service) of an organization's information systems — also known as the CIA
Triad.
Examples of security incidents: a ransomware attack encrypting company servers,
an attacker gaining unauthorized access to a customer database, a phishing email
trick causing an employee to reveal login credentials, a DDoS attack taking down an
e-commerce website during peak sales, or an insider threat employee exfiltrating
proprietary data.
Without a structured incident management process, organizations respond
chaotically, cause additional damage, miss forensic evidence, fail compliance
reporting deadlines, and take far longer to recover. Effective incident management
minimizes all of these harms.

Phases of Incident Management — Flowchart

PHASE 1 — IDENTIFICATION: Detect the incident using

IDS/IPS, SIEM alerts, or user reports

|
V
PHASE 2 — CONTAINMENT: Isolate affected systems
immediately to stop the attack spreading

|
V
PHASE 3 — ERADICATION: Remove all traces of the
threat (malware, backdoors, compromised accounts)

|
V
PHASE 4 — RECOVERY: Safely restore systems to
normal operations from verified clean backups

|
V
PHASE 5 — POST-INCIDENT REVIEW: Analyze what
happened, update IRP, document lessons learned
Detailed Explanation of Each Phase
1. Identification: The first and often hardest phase — recognizing that a security
incident is actually occurring. Many attacks go undetected for months. Identification
requires: 24/7 monitoring via SIEM and IDS/IPS tools, clear criteria defining what
constitutes an incident versus a normal event, a trained Security Operations Center
(SOC) team to analyze alerts, and a user reporting mechanism so employees can
flag suspicious activity. The faster an incident is identified, the less damage it causes
and the lower the cost of recovery. On average, organizations without mature
monitoring take 197 days to detect a breach.
2. Containment: Once an incident is confirmed, the absolute priority is stopping it
from spreading further. Containment has two stages. Short-term containment:
immediate actions like disconnecting infected machines from the network, blocking
malicious IP addresses in the firewall, disabling compromised user accounts, and
isolating affected network segments. Long-term containment: temporary measures
that allow the business to partially continue operating while full eradication is being
prepared — for example, running critical systems on backup infrastructure. Critical:
do NOT simply shut everything down — forensic evidence (memory, logs, network
captures) must be preserved for investigation and potential legal proceedings.
3. Eradication: Eradication means completely removing the threat from the
environment — ensuring no traces remain. Key activities: run full antivirus and
antimalware scans across all systems in the affected segment, identify and patch the
specific vulnerability that was exploited, remove all backdoors, webshells, or remote
access tools installed by the attacker, delete all unauthorized accounts created
during the attack, and reset credentials for ALL accounts that may have been
compromised — not just the confirmed ones. After eradication, the environment must
be confirmed clean before recovery begins.
4. Recovery: Recovery involves carefully restoring normal operations in a
controlled, staged manner. Key steps: restore from verified, cryptographically
authenticated clean backups (never restore from a potentially compromised backup),
apply all relevant security patches before bringing systems back online, monitor
restored systems intensively for the first 24-72 hours for signs of re-infection, validate
that all critical business processes and applications are functioning correctly, and
gradually reconnect isolated systems in a staged manner rather than all at once.
Recovery speed must be balanced with security — rushing recovery often leads to
re-infection.
5. Post-Incident Review: This "Lessons Learned" phase is often skipped due to
time pressure — which is a major mistake. The post-incident review must document:
a complete timeline of events from initial infection to full recovery, how the incident
was detected (and why it was not detected sooner), what the root cause was, which
response actions were effective and which were not, what the total business impact
was (downtime, data loss, cost), and specific recommended improvements to the
IRP and security controls. These findings should be formally presented to
management and used to update all relevant policies and procedures.

Phase Core Question Key Tools / Actions Key Output

1. Is this a real IDS/IPS, SIEM, SOC Incident declaration
Identificatio security incident? team, user reports and initial severity
 Phase Core Question Key Tools / Actions Key Output
n rating
How do we stop it Network isolation, Contained incident;
2.
spreading right account lockout, firewall preserved forensic
Containment
now? rules, IP blocking evidence
Malware removal,
How do we
3. vulnerability patching, Clean, threat-free
completely remove
Eradication credential resets, environment confirmed
the threat?
backdoor removal
Clean backup
How do we safely Systems restored;
restoration, system
4. Recovery return to normal business operations
monitoring, staged
operations? resumed
reconnection
Root cause analysis, IRP
5. Post- What did we learn Updated IRP; lessons
update, management
Incident and how do we learned document;
debrief, compliance
Review improve? compliance evidence
reporting

EXAM TIP Memorize the 5 phases in order. Memory trick: "I Can Eradicate
Really Professionally" (Identification, Containment, Eradication, Recovery,
Post-Incident Review). The difference between Containment (stop it
spreading) and Eradication (remove it completely) is a very common exam
question. CIA Triad (Confidentiality, Integrity, Availability) is the foundation —
always define it.
10. Security Policy
Definition
A security policy is a formal, written, officially approved document that defines how
an organization protects its information assets and how employees, contractors, and
systems must behave to maintain a secure environment. It is the highest-level
governance document in an organization's security program — all other security
standards, procedures, and guidelines flow from it.
A security policy defines WHAT must be done (and why) — not HOW to do it
technically. For example, a policy might state "all remote access must use multi-
factor authentication" (the WHAT). The accompanying standard or procedure would
then specify the exact MFA solution to use and how to configure it (the HOW).
Think of the security policy as the constitution of the organization's security program.
Just like a national constitution does not specify every individual law but sets the
principles that all laws must follow, the security policy sets the principles that all
security decisions must respect.

Components of a Security Policy

Example
Component What It Defines Why It Is Important
Requirement
All privileged
Who can access what Prevents
accounts require
resources, under what unauthorized access
Access Control MFA; access
conditions, and through and limits damage
Policy reviews
what authentication from compromised
conducted
methods accounts
quarterly
Company devices
What employees are Reduces insider may not be used
and are not allowed to threat risk and for personal
Acceptable Use
do with company establishes legal social media or
Policy (AUP)
systems, networks, and basis for disciplinary downloading
data action if violated unauthorized
software
All security
Ensures consistent,
Incident How security incidents incidents must be
coordinated, legally
Response are reported, escalated, reported to IT
compliant response to
Policy contained, and resolved Security within 1
all incidents
hour of discovery
Data How data is categorized Ensures sensitive Customer PII
Classification by sensitivity level and data receives classified as
Policy how each category appropriate protection Confidential must
must be handled, proportional to its be encrypted at
stored, and transmitted value rest using AES-
 Example
Component What It Defines Why It Is Important
Requirement
256 and in transit
using TLS 1.3
Minimum 12
Passwords are the characters;
Minimum password
primary line of uppercase,
requirements ensuring
defense for most lowercase,
Password Policy accounts are protected
systems — weak number, and
by strong, unique
passwords = easy special character
credentials
targets required; 90-day
rotation
Mandates regular
All security
review and updating of
Outdated policies policies reviewed
all security policies to
Periodic Review create false annually and
keep them aligned with
Policy confidence and within 30 days of
evolving threats,
compliance gaps any major
technology changes,
security incident
and new regulations

Detailed Explanation of Each Component

Access Control: Access control is the foundation of information security. The
security policy must define the access control framework using the AAA model:
Authentication (proving who you are — passwords, MFA, biometrics, smart cards),
Authorization (what you are allowed to do after authentication — read-only, read-
write, admin), and Accounting (logging and auditing all access and actions for
accountability and forensic investigation). The access control policy should also
define: the process for requesting new access, how access is modified when an
employee changes roles, and how access is immediately revoked when someone
leaves the organization.
Acceptable Use Policy (AUP): The AUP is a legally binding agreement between
the employer and the employee. Without it, organizations have no basis for
disciplinary action when employees misuse systems. The AUP must cover: internet
usage (what websites are prohibited), email usage (prohibition of sharing confidential
data externally), social media (what can and cannot be shared about the
organization), BYOD (Bring Your Own Device) policies for personal phones and
laptops, remote working security requirements, and data handling procedures (how
to print, share, store, and dispose of sensitive documents). Employees should sign
the AUP at onboarding and when significant changes are made.
Incident Response: The policy must define the incident response framework at a
governance level: what constitutes a reportable security incident, who sits on the
Incident Response Team (IRT) and their specific roles, the escalation chain for
different severity levels, mandatory regulatory reporting requirements (GDPR
requires notification to regulators within 72 hours of discovering a data breach;
HIPAA requires notification within 60 days), evidence preservation requirements for
forensic and legal purposes, and communication protocols for notifying affected
customers or the public.
Periodic Review: A security policy that is never updated becomes a dangerous
liability. As the threat landscape evolves, as new regulations emerge, and as the
organization's technology changes, the policies must keep pace. Review triggers:
mandatory annual review cycle, immediately following any major security incident,
when significant new technology is adopted, when regulatory requirements change,
and when the organization undergoes major structural change (mergers,
acquisitions, major layoffs). The review should involve legal counsel, IT leadership,
senior management, HR, and compliance officers.

Why Security Policies Are Essential

• Legal and Regulatory Compliance: Policies demonstrate due diligence to
regulators and provide the legal framework for disciplinary actions.
• Employee Clarity: Written policies leave no ambiguity about what is expected
— "I did not know" is eliminated as an excuse.
• Audit Readiness: ISO 27001, SOC 2, and PCI DSS all require documented,
approved security policies as a prerequisite for certification.
• Consistency Across the Organization: Policies ensure security decisions are
made consistently based on established principles rather than individual
judgment or convenience.
• Risk Management Framework: Policies create the governance structure that
guides all other risk management and security control decisions.

EXAM TIP Know all 6 components. The AAA framework (Authentication,

Authorization, Accounting) is a very commonly tested concept — always
define all 3. GDPR 72-hour breach notification is a critical exam fact. Know
the difference: Policy = WHAT (governance), Standard = HOW MUCH
(specific requirements), Procedure = HOW (step-by-step instructions). AUP is
signed by employees at onboarding.
11. Conclusion
The deliverable and integration phase is the essential bridge between identifying
security vulnerabilities and actually eliminating them. Without a well-structured
deliverable, even the most thorough penetration test produces zero security
improvement. Without proper integration, recommendations remain on paper while
systems remain exposed and vulnerable.

Topic Core Purpose

Creates a formal, evidence-backed record of all findings
1. The Deliverable
and recommendations
Structures the report with sections tailored to diverse
2. The Document
audiences
Organizes findings by severity and methodology for clear
3. Overall Structure
prioritization
Connects technical vulnerabilities to real business risk and
4. Aligning Findings
compliance obligations
Ensures findings are communicated effectively and drive
5. Presentation
stakeholder action
Plans both immediate fixes and long-term strategic security
6. Integration Summary
improvements
Executes fixes via patching, hardening, access control, and
7. Mitigation
monitoring
Builds proactive, ongoing security through IRP, SIEM, and
8. Defense Planning
regular testing
Provides the 5-phase process for structured response to
9. Incident Management
security incidents
Creates the governance framework that guides all security
10. Security Policy
decisions

Together, these ten elements transform a single point-in-time security assessment

into a continuous, improving security program — one that protects the organization
against today's known vulnerabilities and builds the resilience to withstand
tomorrow's unknown threats.

EXAM TIP For the conclusion of any 16-mark answer: spend 3-4 sentences
summarizing the topic's purpose, the key steps or components, and the
ultimate goal — "strengthen the organization's security posture." A strong
conclusion earns 2 marks and shows the examiner you understood the full
picture, not just memorized facts.