From Assets to Action: A Practical Risk Assessment Walkthrough (With Real Documents)

From Assets to Action: A Practical Risk Assessment Walkthrough (With Real Documents)

Risk assessment is one of those things that sounds simple in theory—but once you actually sit down to do it for a real environment, it quickly becomes clear how much structure and discipline it requires.

Instead of just explaining concepts, I recently completed a full sample risk assessment for a small business environment and documented every step. You can explore the full project here:

In this post, I’ll walk through the entire process, the documents I created, and the key lessons from doing this hands-on.


🏢 The Scenario: XYZ Limited

To make this practical, I created a realistic environment:

XYZ Limited — a small café that offers:

  • Public Wi-Fi for customers
  • A gaming zone (PS5s + PCs)
  • Reception systems for billing
  • An online ordering web application

This setup is simple—but surprisingly rich from a security perspective.

 


 


📌 Step 1: Asset Inventory (Foundation of Everything)

The first document I created was an Asset Inventory.

This included:

  • Hardware (PCs, PS5s, routers, switches)
  • Software (POS system, operating systems)
  • Data (customer database, employee records)
  • Services (web application) 

 

 🔑 Key Insight:

If you miss an asset here, you miss risks later. Everything depends on this step.


⚠️ Step 2: Threat & Vulnerability Register

Next, I mapped:

  • Threats → What can go wrong
  • Vulnerabilities → Why it can happen

Examples from the assessment:

  • Open Wi-Fi → Man-in-the-Middle attacks
  • Web application → SQL Injection
  • Reception PCs → Malware infection
  • Employees → Phishing attacks


📊 Step 3: Risk Analysis Matrix

This is where things get interesting.

I evaluated each risk using:

  • Likelihood (1–5)
  • Impact (1–5)

Then calculated:

Risk Score = Likelihood × Impact

Example:

  • SQL Injection → 5 × 5 = 25 (Critical)
  • Phishing → 4 × 3 = 12 (High)

🔑 Key Insight:

Not all vulnerabilities matter equally—risk analysis helps prioritize what actually matters to the business.


🛡️ Step 4: Risk Treatment Plan (Where Value Is Created)

This is the most important part of the entire process.

For each risk, I defined:

  • Treatment strategy (Mitigate, Avoid, Accept)
  • Specific controls
  • Responsible owner
  • Timeline

Example:

  • SQL Injection → Input validation + WAF
  • Weak passwords → Enforce policy + MFA
  • Open Wi-Fi → Network segmentation

🔑 Key Insight:

Identifying risk is easy. Reducing it in a practical, business-friendly way is the real skill.


🔁 Step 5: Continuous Monitoring

Risk assessment is not a one-time task.

For XYZ Limited, I recommended:

  • Regular vulnerability scans
  • Periodic reassessment
  • Monitoring logs and network activity

🧠 What This Project Taught Me

1. Risk Assessment ≠ Pentesting

As someone with a penetration testing background, this was a mindset shift.

  • Pentesting → Find vulnerabilities
  • Risk assessment → Prioritize based on business impact

2. Business Context Changes Everything

A vulnerability is only important if it affects:

  • Revenue
  • Customer trust
  • Operations

3. Documentation Is Half the Work

Clear, structured documentation:

  • Makes findings actionable
  • Helps stakeholders understand risk
  • Enables decision-making

📂 Final Deliverables

This project includes:

  • Asset Inventory
  • Threat & Vulnerability Register
  • Risk Analysis Matrix
  • (Next step: Risk Treatment Plan)

All documents are structured in a professional, report-ready format.

👉 GitHub: https://github.com/saadibabar/riskassessmentsample
👉 Portfolio: https://starstorm.netlify.app


🚀 Final Thoughts

Risk assessment is where technical security meets business reality.

It forces you to answer:

“What actually matters, and what should we fix first?”

If you’re coming from a technical background (like pentesting), I highly recommend practicing this—it’s a highly valuable skill in real-world security roles.


If you’d like feedback on your own risk assessment work or want to collaborate, feel free to reach out.

🚀 GRC in Action: Connecting Theory to Reality 🚀

 

As part of my GRC studies with Inegben Academy, I'm applying the OCEG Red Book framework to real-world challenges.


1. Third Party Risk Management TPRM 

Why this topic? It's one of the hottest, most tangible, and highest-impact areas in modern GRC. It sits at the intersection of cybersecurity, compliance, operational resilience, and reputation. The OCEG "Red Book" (GRC Capability Model) addresses this under components like "Manage Risk" (PRC Module) and "Objectively Verify & Review" (VV Module) concerning vendor assurance. 

 2. GRC Work Environment Project: "Implementing a Risk-Based Tiered Approach to Vendor Due Diligence"

This isn't just a policy document; it's an operational project.

Project Objectives:

  • Categorize Vendors: Develop a methodology to tier all third parties (Tier 1 - Critical/High Risk, Tier 2 - Medium, Tier 3 - Low). Criteria include: data access, financial impact, integration with core systems, and regulatory alignment.

  • Define Due Diligence Controls: Map specific controls to each tier.

    • Tier 1 (Critical): Comprehensive security questionnaire (e.g., SIG Lite), SOC 2 Type II review, contractually mandated right-to-audit clauses, continuous monitoring (financial health, cyber threats).

    • Tier 2 (Medium): Standard security questionnaire, review of relevant certifications, annual reassessment.

    • Tier 3 (Low): Basic business verification and contract terms.

  • Develop a Workflow: Create a process in the GRC tool (or even SharePoint/Teams initially) for Procurement, IT, and Compliance to trigger and complete due diligence.

  • Establish Ongoing Monitoring: Define how vendors are monitored post-onboarding (e.g., news alerts for breaches, annual financial checks, certificate renewals).

  • Create Exit/Offboarding Procedures: Ensure data destruction and access revocation when contracts end.

Deliverables:

  • TPRM Policy Document.

  • Vendor Tiering Methodology & Questionnaire Library.

  • Process Workflow Diagram & RACI Matrix.

  • Management Dashboard (showing % of vendors by tier, % with completed diligence, high-risk vendors pending action).

3. Case Study: The SolarWinds Sunburst Cyberattack (2020)

This is a perfect, high-profile case study for TPRM failure.

  • What Happened: Russian state-sponsored hackers compromised the software build system of SolarWinds, a major IT management vendor. They inserted a backdoor ("Sunburst") into a legitimate software update. This update was then downloaded by ~18,000 SolarWinds customers, including the U.S. Departments of Treasury, Commerce, Homeland Security, and major tech firms like Microsoft and FireEye.

  • The TPRM Failure Link:

    • Over-Reliance on a Single Vendor: Many organizations treated SolarWinds as a trusted vendor without applying sufficient "critical vendor" scrutiny.

    • Lack of Deep Supply Chain Due Diligence: Due diligence often stops at the direct vendor. This attack exploited the "vendor's vendor" risk—the security of SolarWinds' own development environment.

    • Insufficient Continuous Monitoring: Few customers were monitoring SolarWinds for signs of a compromise in their development or update distribution systems.

    • Consequence: It wasn't a breach of their own systems directly, but a breach via a trusted third party, leading to catastrophic espionage.


 

574r570rm

From Assets to Action: A Practical Risk Assessment Walkthrough (With Real Documents)

From Assets to Action: A Practical Risk Assessment Walkthrough (With Real Documents) Risk assessment is one of those things that sounds simp...