How to Get Cybersecurity Report Effectively

Understanding the Purpose and Scope of a Cybersecurity Report

The scope of a cybersecurity report is dynamic, influenced by organizational size, industry vertical, and regulatory obligations. For instance, a healthcare provider’s report must address HIPAA requirements, while a financial institution prioritizes PCI DSS and SOX compliance. The report’s structure must balance technical depth with executive readability, ensuring stakeholders—from CISOs to board members—grasp both immediate risks and long-term strategic priorities.

Primary Objectives of a Cybersecurity Report

A well-structured cybersecurity report transforms raw data into a strategic narrative, bridging the gap between technical teams and business leadership.

Key Sections of a Cybersecurity Report

1. Executive Summary
   
2. A concise (1–2 pages) snapshot of the organization’s security posture, highlighting top 3 risks, compliance status, and key recommendations.
3. Includes visual aids such as risk heatmaps or trend graphs (e.g., "Phishing incidents increased by 22% YoY").
4. Placeholder: "As of [Report Date], [Organization] faces a high-risk exposure in [Area] due to [Root Cause], with an estimated annualized loss exposure (ALE) of [$X]."
5. Methodology and Scope
   
6. Defines the assessment criteria (e.g., penetration testing, log analysis, third-party audits) and timeframe.
7. Specifies exclusions (e.g., "IoT devices outside IT purview were not assessed").
8. Example: "Scope included 12 critical systems, 500 user accounts, and 3 third-party vendors under PCI DSS Level 1."
9. Threat Landscape Analysis
   
10. External Threats: Trends in ransomware (e.g., LockBit 3.0’s exploitation of ProxyShell), supply chain attacks (e.g., SolarWinds 2020), or state-sponsored campaigns (e.g., APT29 targeting critical infrastructure).
11. Internal Threats: Insider risk factors (e.g., privileged account abuse, data exfiltration via USB drives).
12. Data Source: "Threat intelligence derived from [Source: MITRE ATT&CK, Recorded Future, Darktrace]."
13. Risk Assessment and Prioritization
    
14. Vulnerability Inventory: List of CVEs (e.g., CVE-2023-4966 in Fortra GoAnywhere) with CVSS scores and remediation timelines.
15. Risk Matrix: Categorizes risks by likelihood (Low/Medium/High) and impact (Confidentiality/Integrity/Availability).
16. Formula:

Risk Level = Likelihood × Impact × Control Effectiveness
17. Incident Response and Recovery
    
18. Recent Incidents: Summary of breaches or near-misses (e.g., "Unauthorized access to [System] on [Date] via [Vector]"), including root cause analysis (RCA).
19. Lessons Learned: Gaps in detection (e.g., "SIEM rules missed lateral movement due to lack of EDR integration").
20. Recovery Metrics: "Post-incident, MTTR improved from 4 hours to 15 minutes via automated playbooks."
21. Mitigation Strategies and Roadmap
    
22. Short-Term Actions: Immediate fixes (e.g., "Patch CVE-2023-XXXX within 30 days").
23. Long-Term Initiatives: Strategic projects (e.g., "Deploy XDR by Q4 2024 to reduce false positives by 30%").
24. Budget Allocation: Cost estimates for recommendations (e.g., "$500K for zero-trust architecture").
25. Compliance and Regulatory Alignment
    
26. Gap Analysis: Comparison of current controls vs. GDPR, NIST SP 800-53, or SOC 2 requirements.
27. Audit Findings: Highlights from internal/external audits (e.g., "ISO 27001 audit identified 5 non-conformities in access management").
28. Table Example:

    Standard	Control	Status	Remediation
    GDPR	Article 32 (Security Measures)	Partially Compliant	Implement MFA for all admin accounts by [Date]
    NIST CSF	PR.AC-1 (Access Control Policies)	Compliant	N/A

29. Appendices
    
30. Technical Annexes: Detailed logs, network diagrams, or tool configurations.
31. Glossary: Definitions of terms (e.g., "Zero Trust," "Privileged Access Management").
32. References: Sources for threat data (e.g., "CISA Shields Up Alert, October 2023").

Aligning Report Scope with Organizational Goals and Regulations

1. Regulatory Compliance Mapping
   
2. GDPR: Focuses on data protection, requiring sections on data breaches (Article 33), DPIAs (Data Protection Impact Assessments), and vendor risk assessments.
3. HIPAA: Prioritizes PHI (Protected Health Information) safeguards, mandating audit logs, encryption, and business associate agreements.
4. NIST CSF: Structured around Identify-Protect-Detect-Respond-Recover, with metrics tied to risk tolerance.
5. Example: "For a fintech firm under NYDFS, the report must include a cybersecurity policy review and third-party risk assessment as per 23 NYCRR 500."
6. Industry-Specific Standards
   
7. Healthcare (HITRUST): Emphasizes patient data security and interoperability risks.
8. Critical Infrastructure (CISA): Requires asset inventory, OT/ICS security, and supply chain risk management.
9. Retail (PCI DSS): Focuses on cardholder data environment (CDE) segmentation and penetration testing frequency.
10. Business Objectives Integration
    
11. Digital Transformation: Reports for organizations adopting cloud migration or AI/ML must assess shadow IT risks and model poisoning threats.
12. Mergers/Acquisitions: Due diligence reports should include third-party risk assessments and cultural alignment of security practices.
13. Metric Example: "Reducing customer churn by 1

Gathering and Analyzing Data for the Cybersecurity Report

A comprehensive cybersecurity report relies on structured data collection and rigorous analysis to identify risks, validate threats, and inform strategic decisions. The process involves integrating disparate data sources—such as logs, vulnerability scans, and third-party assessments—while ensuring accuracy, consistency, and actionable insights. This section outlines the essential data sources, methodologies for validation, threat prioritization techniques, and workflows for data normalization to produce a reliable report.


Types of Data Sources Required for a Comprehensive Cybersecurity Report

Cybersecurity reports depend on a combination of internal and external data sources to provide a holistic view of an organization’s security posture. These sources include:

- Operational Logs and Monitoring Data
Logs from SIEM (Security Information and Event Management) tools, IDS/IPS (Intrusion Detection/Prevention Systems), and endpoint detection solutions capture real-time security events, anomalies, and potential breaches. Examples include:


14. SIEM Logs: Security alerts, user authentication failures, and system behavior deviations.
15. Network Traffic Logs: Unusual data transfers, port scans, or lateral movement indicators.
16. Endpoint Logs: Malware detections, unauthorized software installations, or privilege escalations.

- Vulnerability and Threat Intelligence Feeds
Automated scans and external threat intelligence provide context for identified vulnerabilities. Key sources include:


17. Vulnerability Scans: Results from tools like Nessus, OpenVAS, or Qualys, detailing CVEs (Common Vulnerabilities and Exposures) with severity ratings.
18. Threat Intelligence Platforms (TIPs): Feeds from MISP, AlienVault OTX, or commercial providers (e.g., FireEye, CrowdStrike) that classify emerging threats by TTPs (Tactics, Techniques, and Procedures).
19. Third-Party Assessments: Penetration test reports, compliance audit findings (e.g., ISO 27001, NIST CSF), or vendor security evaluations.

- Incident and Forensic Data
Post-incident analyses, including:


20. Incident Response Reports: Documentation of containment efforts, root causes, and remediation steps.
21. Forensic Artifacts: Memory dumps, disk images, or network packet captures from investigations.
22. User Behavior Analytics (UBA): Anomalies detected via tools like Splunk User Behavior Analytics or Microsoft Defender for Identity.

- Configuration and Compliance Data
Baselines for security controls, including:


23. Configuration Management Databases (CMDB): Asset inventories, patch levels, and misconfigured services.
24. Compliance Frameworks: Mapping against NIST SP 800-53, GDPR, or sector-specific regulations (e.g., HIPAA for healthcare).

Critical Consideration: Data sources must align with the report’s scope—e.g., a financial services report may prioritize PCI DSS logs, while a healthcare report emphasizes HIPAA-related access controls.

Step-by-Step Procedure for Collecting and Validating Data from SIEM, IDS/IPS, and Endpoint Solutions

The validation process ensures data integrity by cross-checking raw inputs against known benchmarks and eliminating false positives. Below is a structured workflow:

1. Data Extraction and Aggregation


25. SIEM Tools: Export logs in standardized formats (e.g., CEF, Syslog, or JSON) from platforms like Splunk, IBM QRadar, or Microsoft Sentinel.
26. IDS/IPS Systems: Retrieve alert logs from Cisco Firepower, Palo Alto Networks, or Snort, focusing on signatures triggered (e.g., CVE-2023-XXXX).
27. Endpoint Solutions: Collect telemetry from EDR/XDR tools (e.g., CrowdStrike, SentinelOne) via APIs or direct exports, including:
28. Process execution logs.
29. File integrity monitoring (FIM) alerts.
30. Behavioral anomalies (e.g., unusual command-line arguments).

2. Timestamp and Source Verification


31. Align timestamps across all logs to detect time-based inconsistencies (e.g., a SIEM alert at 14:00 with no corresponding endpoint event).
32. Validate source IP addresses against DHCP leases or VPN logs to rule out spoofed entries.

3. Normalization and Format Standardization


33. Convert disparate log formats into a unified schema (e.g., using tools like Logstash or Apache NiFi) to facilitate correlation.
34. Example normalization rules:
35. Map "src_ip" fields across tools to a consistent naming convention.
36. Standardize severity levels (e.g., "High" = CVSS ≥ 7.0).

4. Cross-Referencing with External Feeds


37. Enrich raw data with threat intelligence by:
38. Matching IPs/domains against blocklists (e.g., Abuse.ch, AlienVault).
39. Overlaying vulnerability scans with CVE databases (NVD, MITRE ATT&CK).
40. Example: A SIEM alert for "Suspicious PowerShell activity" can be validated by checking if the detected command aligns with a known ATT&CK technique (e.g., T1059.001).

5. Automated Validation Checks


41. Use scripts (Python, Bash) to:
42. Flag missing fields (e.g., no "user_agent" in a web traffic log).
43. Detect duplicate entries within a 5-minute window.
44. Implement checksum validation for critical datasets (e.g., comparing hash values of exported logs).

Best Practice: Automate validation where possible to reduce human error, but retain manual review for high-stakes data (e.g., incident-related logs).

Methods to Identify and Prioritize Critical Threats or Vulnerabilities

Raw data must be translated into actionable insights by applying risk assessment frameworks. The following methods ensure threats are prioritized based on likelihood, impact, and exploitability.

1. Quantitative Scoring Systems


45. CVSS (Common Vulnerability Scoring System):
Assigns a numerical score (0–10) to vulnerabilities based on exploitability (e.g., network access, authentication requirements) and impact (e.g., data loss, system availability).

46. Example: A CVSS 9.8 (Critical) vulnerability in an exposed RDP service warrants immediate patching.
47. Risk Matrices:
Combine probability (e.g., "Likely" vs. "Unlikely") with impact (e.g., "Catastrophic") to categorize risks into quadrants (e.g., "High Risk" = High Probability + High Impact).

2. Threat Hunting and Anomaly Detection


48. Behavioral Baselining: Compare current logs against historical norms (e.g., using machine learning in tools like Darktrace or Vectra) to detect deviations.
49. Hypothesis-Driven Analysis: Test specific scenarios (e.g., "Are lateral movement attempts correlated with phishing emails?") by querying:
50. SIEM for failed logins post-phishing.
51. EDR for unusual process trees (e.g., `lsass.exe` spawning `powershell.exe`).

3. Contextual Enrichment


52. Overlay operational data with business context:
53. Asset Criticality: A vulnerability in a payment gateway (Tier 1 asset) may be prioritized over one in a test server (Tier 3).
54. Threat Actor TTPs: Cross-reference detected activity with known groups (e.g., APT29 targeting specific industries).

4. Dependency Mapping


55. Identify cascading risks by analyzing:
56. Service Dependencies: A compromised DNS server may impact multiple applications.
57. Third-Party Risks: Vulnerabilities in cloud providers (e.g., AWS S3 misconfigurations) or SaaS tools (e.g., unpatched Slack apps).

Example Workflow:
A SIEM alert for "Brute Force Attack" on an internal RDP server is prioritized as follows:
1. CVSS score of the underlying vulnerability (if any) = 7.5 (High).
2. Risk Matrix: Probability = "High" (observed in logs), Impact = "High" (potential data exfiltration).
3. Context: The server hosts sensitive HR records → Critical Priority.

Correlating Disparate Data Sources to Uncover Patterns or Anomalies

Isolated data points often lack context; correlation reveals hidden relationships between seemingly unrelated events. The following techniques enable cross-source analysis:

1. Event Chaining


58. Reconstruct attack sequences by linking:
59. Initial Access: Phishing email (detected via email security tool) → User clicks link → SIEM alert for unusual outbound connection.
60. Lateral Movement: EDR detects `PsExec` usage → SIEM shows failed logins on a domain controller.
61. Tools: Use SIEM playbooks (e.g., Splunk SPL queries) or graph databases (e.g., Neo4j) to visualize relationships.

2. Temporal Correlation
-




Structuring and Writing the Cybersecurity Report

A well-structured cybersecurity report transforms raw data into a strategic asset, enabling stakeholders to assess risks, allocate resources, and implement proactive measures. Effective report writing balances technical depth with clarity, ensuring executives, compliance officers, and IT teams derive actionable insights. This section outlines a standardized framework for organizing content, presenting data, and distilling findings into concise, impactful narratives tailored to diverse audiences.


Report Outline Using a Modular Section Structure

Cybersecurity reports should adhere to a logical flow that aligns with stakeholder priorities while maintaining consistency in presentation. Below is a table-based outline that categorizes key sections, their purpose, and recommended content depth.


Section	Purpose	Key Components	Target Audience
Executive Summary	Provides a high-level overview of risks, incidents, and recommendations.	Top 3 critical findings (quantified where possible). Strategic recommendations with estimated cost/benefit. Key performance indicators (KPIs) vs. benchmarks.	C-Level Executives, Board Members
Threat Intelligence Overview	Contextualizes the cyber threat landscape relevant to the organization.	Trends in attack vectors (e.g., phishing, ransomware) with regional data. Industry-specific threats (e.g., healthcare: HIPAA breaches, finance: credential stuffing). Dark web monitoring insights (e.g., leaked credentials, exposed APIs).	Security Teams, Risk Officers
Incident Response Metrics	Evaluates the effectiveness of detection, response, and recovery processes.	Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) by incident type. Number of false positives/negatives in monitoring systems. Post-incident review findings (root causes, lessons learned).	IT Security, Compliance, Incident Response Teams
Compliance Status	Demonstrates adherence to regulatory frameworks (e.g., GDPR, NIST, ISO 27001).	Audit findings with remediation timelines. Gaps in controls (e.g., missing encryption, outdated policies). Third-party vendor compliance assessments.	Compliance Officers, Legal Teams
Risk Assessment and Prioritization	Identifies high-impact risks and justifies mitigation strategies.	Risk heatmaps (likelihood vs. impact matrix). Cost of inaction (e.g., "Failure to patch CVE-2023-XXXX could result in $5M in fines"). Alignment with business objectives (e.g., "Mitigating supply chain risks supports Q3 revenue targets").	Risk Management, CISO
Actionable Recommendations	Translates findings into specific, measurable steps.	Short-term fixes (e.g., "Deploy EDR on all endpoints by EOY"). Long-term initiatives (e.g., "Establish a SOC-as-a-Service partnership"). Resource requirements (budget, headcount, third-party tools).	All Stakeholders

Presenting Quantitative Data in Tables

Quantitative data must be visually scannable and contextually clear to avoid misinterpretation. Below are examples of structured tables with labels, units, and trend analysis.


Incident Response Metrics (Q1-Q3 2023)

Metric	Q1	Q2	Q3	Trend	Benchmark*
Mean Time to Detect (MTTD) - Hours	48	36	24	↓ 50% YoY (Improvement due to SIEM upgrades)	≤ 24 hours (NIST SP 800-61)
Mean Time to Respond (MTTR) - Hours	12	8	6	↓ 33% (Automated playbooks reduced manual intervention)	≤ 12 hours (Industry average)
False Positives per 1,000 Alerts	120	85	60	↓ 50% (Tuned detection rules)	≤ 50 (SOC maturity model)
*Benchmarks sourced from MITRE ATT&CK Enterprise and Verizon DBIR 2023.

Key Design Principles for Data Tables:

62. Units: Always specify units (e.g., "hours," "alerts/1,000") to prevent ambiguity.
63. Trends: Include arrows (↑/↓) or color-coding (green/red) to highlight improvements or declines.
64. Benchmarks: Compare internal metrics against industry standards (e.g., NIST, ISO, or vendor reports).
65. Annotations: Use footnotes to explain outliers (e.g., "Spike in Q2 due to vendor breach").

Writing Executive Summaries for Non-Technical Stakeholders

Executive summaries distill complex cybersecurity findings into three critical elements: risk exposure, business impact, and recommended actions. The goal is to answer:
"What keeps me up at night, and how do we fix it?"

Structure for Clarity:
1. Opening Hook: Start with a high-impact statement.
>

> "In Q3 2023, [Organization] faced a 40% increase in phishing attempts targeting executive emails, with one successful breach resulting in a $1.2M ransom demand. Without intervention, this trend risks violating GDPR Article 32 and exposing customer PII." >

2. Risk Prioritization: Use a risk heatmap (described in text) to visually rank threats.
> "Of the 15 critical vulnerabilities identified, 60% stem from unpatched third-party software, posing the highest likelihood of exploitation (7/10 likelihood, $8M potential impact)."

3. Business Alignment: Connect cybersecurity to financial or operational goals.
> *"Mitigating these risks aligns with our Q4 objective to reduce operational downtime by 20%. The proposed $500K investment in extended detection and response (XDR) would yield a 3:1 ROI by preventing a single ransom


Incorporating Threat Intelligence and Incident Analysis

Threat intelligence and incident analysis serve as critical pillars in cybersecurity reporting, enabling organizations to contextualize internal vulnerabilities within broader threat landscapes while quantifying the tangible and intangible impacts of security breaches. By integrating structured frameworks such as MITRE ATT&CK and CISA advisories, reports can transition from static snapshots of risk to dynamic, actionable assessments. This section outlines a systematic approach to embedding external threat intelligence, analyzing past incidents, and benchmarking findings against industry trends, ensuring the report aligns with both proactive and reactive security strategies.


Framework for Integrating External Threat Intelligence

External threat intelligence provides a real-time snapshot of adversary tactics, techniques, and procedures (TTPs), allowing organizations to correlate internal findings with global cyber threats. A structured framework for integration involves sourcing, filtering, and contextualizing intelligence to avoid alert fatigue while enhancing situational awareness.

Key steps for implementation:

• Source Selection and Prioritization
  Curate intelligence feeds from authoritative sources such as:
  • MITRE ATT&CK®: Framework mapping adversary behaviors to observable techniques (e.g., "Phishing" mapped to T1566.001 for Spearphishing Attachment).
  • CISA Alerts and Binders: Government-backed advisories on active campaigns (e.g., CISA AA23-002A on Log4j exploits).
  • Industry-Specific Threat Feeds: ISACs (Information Sharing and Analysis Centers) for sectors like finance (FS-ISAC) or healthcare (H-ISAC).
  • Commercial Threat Intelligence Platforms: Tools like Recorded Future, FireEye, or CrowdStrike, which aggregate and analyze open-source intelligence (OSINT).
  Prioritize feeds based on relevance to the organization’s asset inventory, threat landscape, and risk appetite. For example, a healthcare provider should emphasize feeds highlighting HIPAA violations or ransomware targeting medical devices.
• Mapping to Internal Assets and Controls
  Translate raw intelligence into actionable insights by:
  • Cross-referencing MITRE ATT&CK techniques with internal detection logs (e.g., identifying if "Credential Dumping" (T1003) appears in SIEM alerts).
  • Aligning CISA advisories with NIST CSF (Identify, Protect, Detect, Respond, Recover) functions to assess gaps in existing controls.
  • Using threat modeling (e.g., STRIDE or PASTA) to evaluate how external TTPs could exploit internal weaknesses (e.g., unpatched software or misconfigured cloud storage).
  Example: If a CISA alert warns of "Initial Access Brokers" exploiting zero-day vulnerabilities in VPN appliances, the report should include a table mapping affected internal VPN models (e.g., Fortinet, Pulse Secure) to patch status and mitigation timelines.
• Contextualizing with Internal Data
  Combine external intelligence with internal telemetry (e.g., EDR/XDR logs, firewall rules) to:
  • Validate whether observed TTPs (e.g., Cobalt Strike beacons) match internal incident patterns.
  • Assess dwell time of threats (e.g., "APT29 used stolen credentials for 45 days before detection" → benchmark against internal mean time to detect (MTTD)).
  • Highlight emerging trends (e.g., increase in "Living-off-the-Land" attacks using legitimate tools like PowerShell or WMI).
  Visualization Tip: Use heatmaps in the report to show correlation strength between external threats and internal alerts, with color gradients indicating severity (e.g., red for confirmed matches, yellow for potential overlaps).

Analyzing Past Security Incidents with Root Cause Techniques

Post-incident analysis transforms reactive responses into strategic improvements by identifying systemic vulnerabilities. Root cause analysis (RCA) techniques such as the "5 Whys" or fishbone diagrams (Ishikawa) provide structured methodologies to dissect incidents without attributing blame. These methods ensure findings are objective, repeatable, and aligned with organizational risk mitigation goals.

Structured RCA methodologies for cybersecurity incidents:

• The "5 Whys" Method
  A iterative questioning technique to peel back layers of an incident until the fundamental cause is uncovered. Applied to cybersecurity, it focuses on:
  • Technical Failures: "Why did the ransomware encrypt the database?" → "Because the backup was not immutable."
  • Process Gaps: "Why was the backup not tested?" → "Because the DR plan lacked automated validation."
  • Human Factors: "Why did the employee click the phishing link?" → "Because security awareness training did not simulate real-world lures."
  Example:

  Incident: Lateral movement by an attacker post-phishing.

  1. Why did the attacker move laterally? → They exploited default admin credentials.
  2. Why were default credentials still in use? → The password rotation policy was not enforced.
  3. Why was the policy not enforced? → The SIEM lacked alerts for credential reuse.
  4. Why were SIEM alerts missing? → The correlation rules were not updated for new attack patterns.
  5. Why were rules outdated? → The SOC team lacked access to threat intelligence feeds.

  Root Cause: Siloed threat intelligence and inadequate SIEM rule maintenance.

• Fishbone Diagram (Ishikawa)
  A visual tool categorizing root causes into 6Ms: Manpower, Machine, Method, Material, Measurement, and Mother Nature (Environment). For cybersecurity, adapt categories to:
  • People: Training gaps, insider threats, or misconfigured access.
  • Process: Missing approval workflows, unpatched systems, or inadequate logging.
  • Technology: Vulnerable software, misconfigured cloud services, or outdated firewalls.
  • Data: Poor data classification or unencrypted sensitive information.
  • External Factors: Supply chain risks, third-party breaches, or regulatory changes.
  Example:

  Incident: Data breach via a compromised vendor’s system.

  Category	Root Cause	Mitigation
  Process	Vendor risk assessments were conducted annually instead of quarterly.	Implement continuous monitoring with automated alerts for vendor security posture changes.
  Technology	Shared credentials between the organization and the vendor.	Enforce MFA and unique credentials for all third-party access.
  People	Lack of vendor security training for internal teams.	Mandate vendor security awareness modules for all employees interacting with third parties.

• Quantitative RCA with Metrics
  Assign numerical values to root causes to prioritize fixes based on impact and likelihood. Metrics may include:
  • Financial Impact: Cost of incident response (e.g., $250K for ransomware recovery).
  • Operational Downtime: Hours of system unavailability (e.g., 72 hours for a DDoS attack).
  • Compliance Violations: Number of regulatory fines (e.g., GDPR penalties for data exposure).
  • Reputational Risk: Media mentions or customer churn (e.g., 5% drop in sales post-breach).
  Formula for Root Cause Scoring:

  Root Cause Severity Score = (Financial Impact × 0.4) + (Operational Impact × 0.3) + (Compliance Risk ×

  A well-crafted cybersecurity report is more than a snapshot of current vulnerabilities—it is a roadmap for resilience. By systematically gathering data from SIEM tools, penetration tests, and third-party audits, and structuring findings with clarity, organizations empower decision-makers to prioritize resources, allocate budgets, and communicate risks with confidence. The key lies in translating complex technical details into concise, visually supported insights, ensuring executives grasp the urgency of threats while IT teams receive executable recommendations. Ultimately, the report’s value hinges on its ability to turn data into decisive action, reducing exposure and fortifying defenses against both known and evolving cyber threats.

  • compliance frameworks
  • cybersecurity reporting
  • data driven security
  • incident response metrics
  • threat intelligence integration

  Leave a Comment

  Name

  Comment

  Post Comment

  Comments are moderated before appearing. The data you submit is processed according to the Privacy Policy of ir.msu.ac.zw.