Run my security
risk assessment lab.

Make it your own. This is how I did it, not the only way. Feel free to adjust the lab to your liking: change the names, tools, or scope, or take it further. What matters is that you understand what you built and why.

How it fits together

1. Scope the systemPick an organization and what you’re assessing.
2. Categorize with FIPS 199Rate impact on C, I, and A.
3. Find control gapsMap deficiencies to NIST 800-53.
4. Plan remediationRisk-based fixes, RBAC, access reviews.
5. Track with a POA&MOwners, deadlines, status, evidence.

Step by step

1. Scope your system

   Read the Bayou Bites Café scenario above. In a few sentences, describe what you’re assessing: the business, its systems, the data it handles (especially card payments), and who uses each system.

2. Categorize it with FIPS 199

   Rate the potential impact of a loss of confidentiality, integrity, and availability as low, moderate, or high. The highest of the three sets the overall category. Write it in the FIPS 199 format:

   textCopy

   SC Bayou Bites POS = {(confidentiality, ?), (integrity, ?), (availability, ?)}

   Ask yourself: what happens if card data leaks (C)? If prices or orders are changed (I)? If the registers go down on a Friday night (A)?

3. Identify control gaps

   Go through the nine assessment notes in the scenario. For each one, write the finding in your risk register and map it to a NIST SP 800-53 Rev. 5 control (or a PCI DSS requirement). My lab focused on these controls:

   • AC-6 Least Privilege: users have more access than their job needs.
   • CA-5 Plan of Action and Milestones: findings are not tracked to completion.
   • CA-7 Continuous Monitoring: security status is not watched over time.
   • RA-3 Risk Assessment: risks are not formally identified and rated.
   • RA-7 Risk Response: there is no defined way to respond to findings.

4. Rate the risk

   For each gap, rate its impact and how likely it is to happen, then combine them with this simple matrix. Fix the Highs first.

   textCopy

                    Impact: Low    Moderate   High
   Likelihood High:         Moderate  High       High
   Likelihood Moderate:     Low       Moderate   High
   Likelihood Low:          Low       Low        Moderate

   The first row of the risk register worksheet is filled in as an example.

5. Write remediation strategies

   For each control, write a risk-based remediation strategy that explains what changes, why it reduces risk, and who owns it.

6. Recommend RBAC and access reviews

   Design role-based access so people only get what their role needs, and add periodic access reviews to catch excessive access to sensitive information.

7. Build a POA&M tracker

   Create a Plan of Action and Milestones to track remediation to completion. My tracker covered risk severity, ownership, deadlines, status, and evidence. Use the POA&M worksheet above. Its first row shows a finished example:

   textCopy

   ID | Weakness | NIST control | Risk severity | Owner | Milestones | Due date | Status | Evidence of completion

8. Write a PCI DSS-aligned policy

   Write a short security policy for Bayou Bites’ point-of-sale environment. Name a technical owner for each requirement. A simple outline:

   1. Purpose and scope: which systems and locations it covers.
   2. Network security controls: keep the POS on its own network, separate from guest Wi-Fi.
   3. Secure configuration: change every vendor default password before a device goes live.
   4. Malware protection: keep antivirus current on every back-office computer.
   5. Roles and ownership: who is responsible for each requirement.
   6. Review: how often the policy is reviewed and updated.

9. Compare with the answer key

   When you’re done, open the answer key at the top of the page and compare. It’s fine if your mappings differ, as long as you can explain why.

Check your work

• Every gap is mapped to a specific NIST SP 800-53 control.
• Each finding has a CIA impact rating and a priority.
• Every POA&M item has an owner, a due date, a status, and evidence.
• Your policy names an owner for each requirement.

This walkthrough follows my lab. Portals and menus change over time, so names may look slightly different when you try it. See my original write-up on GitHub