NIST 800-53 Risk Assessment Package

Build a GRC portfolio with FIPS 199 categorization and a POA&M.

Introduction

30 Second Summary

Every time a Georgia resident submits a benefit application online, a state agency is responsible for protecting their Social Security Number, income data, and personal details. The process that determines whether those protections are adequate is called a risk assessment.

In this project, you will build a complete NIST SP 800-53 Rev 5 risk assessment package for a fictional Georgia state agency system. You'll categorize the system, assess controls, identify gaps, score risks, and produce a remediation plan published as a professional GitHub portfolio.

What You'll Build

When you're done, you'll have a public GitHub repository that a hiring manager can click through to see your system security profile, read your control assessments, review your risk scoring logic, and evaluate your tracked remediation plan.

By the end of this project, you'll have:

  • A System Security Profile with FIPS 199 categorization and control implementation statements across key security families that document exactly how each security measure is (or isn't) met.
  • A gap analysis with a likelihood x impact risk scoring matrix that turns raw findings into prioritized decisions a security team can act on.
  • A Plan of Action and Milestones (POA&M) with tracked remediation items, owners, timelines, and resources that proves you don't just find problems. You solve them.
  • Secret Mission: Write an executive risk brief that translates your technical findings into business language for non-technical leadership.

Are there any prerequisites?

This project assumes basic familiarity with NIST frameworks and cybersecurity concepts from coursework or self-study. You do not need prior experience writing formal assessment documents.

Before We Start

Before we dive into building your risk assessment package, take a moment to commit to what you're creating and why it matters.

Set Up Your Tools

Your risk assessment package will be a set of professional Markdown documents stored in a public GitHub repository. For a hiring manager to see your work, you need a way to write and version-control those documents locally, then push them to the web.

In this step, you'll install VS Code for writing, Git for version control, and create a GitHub repository where the finished package will live.

In this step, get ready to:
  • Install VS Code and Git on your Windows machine.
  • Create a GitHub account and a public portfolio repository.
  • Clone the repository locally and open it in VS Code.
Install Visual Studio Code

VS Code is a free code editor that handles Markdown files, has a built-in terminal, and integrates with Git. It will be your workspace for the entire project.

  • Open your browser and go to https://code.visualstudio.com/download.
  • Click the Windows button to download the x64 User Installer.
  • Once the download finishes, double-click the installer file to run it.

What will the installer ask?

The installer walks you through a short wizard. Accept the license agreement, keep the default install location, and on the Additional Tasks screen make sure Add to PATH is checked. Click Install, then Finish.

  • Press the Windows key on your keyboard to open the search bar.
  • Type Visual Studio Code and press Enter to open it.

You should see the VS Code Welcome tab appear. That confirms the install worked.

VS Code not appearing in search?

If the search doesn't find VS Code, the installer may not have added it to your PATH. Try restarting your computer, then searching again.

Help me troubleshoot my VS Code installation on Windows.

Install and configure Git

Git tracks every change you make to your files and lets you push them to GitHub. You'll install it using Windows' built-in package manager.

  • Press the Windows key, type PowerShell, and press Enter to open it.
  • Install Git by running this command:
winget install --id Git.Git -e --source winget

What does this command do?

This uses winget, the Windows package manager, to download and install Git. The --id Git.Git flag tells it to install the official Git for Windows package.

The install takes a minute or two. Once it finishes, you need to close and reopen VS Code so it picks up the new Git installation.

  • Close VS Code completely.
  • Reopen VS Code using the Windows key search (type Visual Studio Code, press Enter).
  • Open the built-in terminal by pressing Ctrl+` (the backtick key, above Tab).

Before you run the next command, what do you think you'll see if Git installed correctly?

  • Confirm Git is installed by running this command in the VS Code terminal:
git --version

✔️ I see a version number

You should see something like git version 2.55.0.windows.3. The exact number doesn't matter as long as a version prints. Git is ready to go.

ⓧ Command not found

If you see an error like "git is not recognized," the terminal hasn't picked up the new PATH entry yet.

  • Close VS Code completely and reopen it.
  • Open a fresh terminal with Ctrl+` and try git --version again.
  • If it still fails, restart your computer fully, then reopen VS Code and try the command one more time.

Help me troubleshoot Git not being recognized in my VS Code terminal on Windows.

Now configure your Git identity so your commits are labeled with your name.

  • Set your name by running this command (replace the placeholder with your actual name):
git config --global user.name "[[YOUR_NAME="Your Name"]]"
  • Set your email by running this command (use the email you'll use for GitHub):
git config --global user.email "[[YOUR_EMAIL="your-email@example.com"]]"

Why do I need to set my name and email?

Every Git commit records who made the change. These config values attach your identity to the work. Use the same email you'll register with on GitHub so your commits link to your profile.

Create your GitHub repository

GitHub is where hiring managers will view your finished risk assessment package. You need a public repository so anyone with the link can see your work.

  • Open your browser and go to https://github.com.
  • Click Sign up and follow the prompts to create your account.
  • Check your email inbox and click the verification link GitHub sends you.

Already have a GitHub account?

If you already have an account, sign in and skip straight to creating the repository below.

Now create the repository that will hold your assessment documents.

  • Click the + icon in the upper-right corner of GitHub.
  • Select New repository.
  • In the Repository name field, enter nist-800-53-risk-assessment.
  • Set the visibility to Public.
  • Check the box labeled Add a README file.
  • Click Create repository.

GitHub takes you to your new repository page. You should see a single README.md file listed.

Why does the repository need to be public?

A public repository means anyone with the link can view your files. This is what lets a hiring manager click through your assessment artifacts directly from your resume.

Now clone the repository to your local machine so you can work on the files in VS Code.

  • On your repository page, click the green Code button.
  • Make sure HTTPS is selected, then click the copy icon to copy the URL.
  • Switch back to VS Code and its terminal.
  • Navigate to your Desktop by running this command:
cd ~/Desktop
  • Clone your repository by running this command (replace the username placeholder with your GitHub username):
git clone https://github.com/[[GITHUB_USERNAME="YOUR-USERNAME"]]/nist-800-53-risk-assessment.git

You should see output ending with "done" confirming the files were downloaded.

  • Open the cloned folder in VS Code by clicking File in the top menu bar.
  • Click Open Folder.
  • Navigate to your Desktop, select the nist-800-53-risk-assessment folder, and click Select Folder.

Look at the Explorer sidebar on the left. You should see README.md listed as the only file. That confirms your repository is cloned and ready for work.

Don't see README.md in the sidebar?

Make sure you opened the nist-800-53-risk-assessment folder itself, not the Desktop folder that contains it. The Explorer should show the repository name at the top.

If the Explorer panel is hidden, press Ctrl+Shift+E to toggle it open.

Help me troubleshoot opening my cloned repository in VS Code.

Your workspace is ready. You have VS Code for writing, Git for tracking changes, and a live GitHub repository waiting for your assessment documents. Next up, you'll define the fictional system you're assessing and perform your FIPS 199 categorization.

Define the System and Categorize with FIPS 199

Your tools are ready and your repository is live on GitHub. Now you need to define exactly what you're protecting.

Before you can assess any security controls, you need to know what system you're evaluating and how much damage a breach would cause. FIPS 199 categorization determines which controls apply and at what rigor. Skip this step and your entire assessment is built on sand.

In this step, get ready to:
  • Create a system security profile documenting what the Georgia Citizen Services Portal does and what it connects to.
  • Perform a FIPS 199 security categorization that assigns impact levels to confidentiality, integrity, and availability.
  • Commit and push your work to GitHub so it's visible in your portfolio.
Create the system profile document

Every NIST SP 800-53 assessment starts with a System Security Profile. This document answers three questions: what is the system, who owns it, and where does its boundary end?

  • In VS Code, right-click in the Explorer sidebar and select New File.
  • Name the file system-security-profile.md and press Enter.
  • Paste the following system identification section into the file:
# System Security Profile - Georgia Citizen Services Portal (GCSP)

## System Identification

| Attribute | Detail |
|-----------|--------|
| System Name | Georgia Citizen Services Portal (GCSP) |
| System Owner | Georgia Department of Community Affairs (fictional) |
| Information System Security Officer | Jane Mitchell, ISSO (fictional) |
| Authorizing Official | Robert Chen, Deputy Director of IT (fictional) |
| System Type | Major Application |
| Operational Status | Operational |
| Deployment Model | Hybrid (on-premises application servers, cloud-hosted database) |

What does this section do?

The System Identification table establishes accountability. It names who owns the system, who is responsible for its security (the ISSO), and who has the authority to accept its risks (the Authorizing Official).

In a real Georgia state agency, these names would tie to actual personnel. For your portfolio, fictional names demonstrate you know the roles that must be assigned.

  • Save system-security-profile.md by pressing Ctrl+S.
  • You should see the Markdown table rendered in the editor with pipe-separated columns.

Next, you need to describe what the system actually does and where its boundaries are. This tells an assessor what is in scope for the security evaluation.

  • Add the following system description and boundary section below the identification table:
## System Description

The Georgia Citizen Services Portal (GCSP) is a web-based application that enables Georgia residents to apply for state benefit programs, upload supporting documentation, and check application status. The system processes approximately 15,000 applications per month and stores personally identifiable information (PII) including full names, Social Security Numbers, home addresses, dates of birth, and income documentation.

## System Boundary

The authorization boundary includes the following components:

- Web Server: IIS-based front-end serving the citizen-facing portal
- Application Server: .NET application processing business logic and form submissions
- Database Server: SQL Server storing citizen PII and application records
- Network Perimeter: Firewall, intrusion detection system, and VPN gateway
- Authentication Service: Active Directory integration for staff access; citizen accounts use username/password

Components explicitly outside the boundary:
- Third-party payment processing (handled by external vendor under separate ATO)
- State email system (managed under enterprise authorization)
- Physical facility security (covered by site-level security plan)

Why define a system boundary?

The boundary draws a line around what you're responsible for assessing. Anything inside the boundary gets assessed against NIST controls. Anything outside is someone else's responsibility under a separate authorization.

Listing what is explicitly outside the boundary is just as important as listing what is inside. It prevents scope creep and shows the assessor you've thought about where one system ends and another begins.

  • Save system-security-profile.md.
  • Scroll through the file in VS Code. You should see the identification table at the top, a description paragraph, and bullet lists defining what is inside and outside your system boundary.

File looks like raw text instead of formatted Markdown?

Make sure your file ends with the .md extension. VS Code uses the extension to enable Markdown syntax highlighting. If you named it system-security-profile.txt or left off the extension entirely, rename it now.

help me rename my file to have a .md extension in VS Code

Perform FIPS 199 categorization

Now you know what the system is. The next question is: how bad would it be if something went wrong? FIPS 199 gives you a structured way to answer that by rating the impact of a breach on three security objectives: confidentiality, integrity, and availability.

  • Add the FIPS 199 section header and information types table below the System Boundary section:
## FIPS 199 Security Categorization

### Information Types Processed

| Information Type | Description |
|-----------------|-------------|
| Citizen PII | Names, SSNs, addresses, dates of birth |
| Benefit Application Data | Income records, household composition, eligibility determinations |
| System Authentication Data | Staff credentials, citizen account credentials |
| Audit Logs | System access records, transaction logs |

Why list information types first?

The information types drive your impact ratings. A system that stores Social Security Numbers has very different confidentiality requirements than one that stores public park schedules. By listing the data types explicitly, you show the assessor the evidence behind your categorization decisions.

  • Save the file and confirm you can see the Information Types table below your boundary section.
  • Now add the impact assessment and overall categorization below the information types table:
### Impact Assessment

| Security Objective | Impact Level | Rationale |
|-------------------|-------------|----------|
| Confidentiality | MODERATE | Unauthorized disclosure of citizen PII (SSNs, income data) could cause serious harm to affected individuals including identity theft and financial loss |
| Integrity | MODERATE | Unauthorized modification of benefit application data could result in incorrect eligibility determinations and improper payments, causing financial harm to the agency and citizens |
| Availability | LOW | Temporary system unavailability would cause limited inconvenience to citizens (they can apply in person or by phone) but would not result in physical harm or significant financial loss |

### Overall System Categorization

**SC GCSP = {(Confidentiality, MODERATE), (Integrity, MODERATE), (Availability, LOW)}**

**Overall Impact Level: MODERATE** (high-water mark per FIPS 199 Section 4)

The system is categorized as MODERATE impact. This determination drives the selection of NIST SP 800-53 Rev 5 Moderate baseline controls for assessment.

What is the high-water mark rule?

FIPS 199 says the overall system categorization equals the highest impact level assigned to any single security objective. Even though Availability is LOW, the system is categorized as MODERATE overall because both Confidentiality and Integrity are MODERATE.

This ensures the system is protected at a level that matches its most sensitive characteristic. The overall level determines which NIST SP 800-53 Rev 5 control baseline you select for assessment.

  • Save system-security-profile.md.
  • Scroll to the bottom of the file. You should see the Impact Assessment table with three rows (Confidentiality, Integrity, Availability) followed by the overall MODERATE categorization statement.

Table columns look misaligned?

Markdown tables do not need to be visually aligned in the source to render correctly. The pipes (|) separate columns regardless of spacing. If you see pipes and dashes in the right places, your table is correct even if the columns look uneven in the editor.

help me check if my Markdown table is correctly formatted

Commit and push to GitHub

Your system security profile is complete. Time to commit it to Git and push it to your GitHub repository so it becomes part of your public portfolio.

Before you push, predict what you expect to see on your GitHub repository page after the push completes.

  • Commit and push your system security profile by running these commands in the VS Code terminal:
git add system-security-profile.md
git commit -m "Add system security profile"
git push
  • Open your repository on GitHub by visiting https://github.com/ and clicking your nist-800-53-risk-assessment repository.
  • You should see system-security-profile.md listed alongside your README.md. Click on system-security-profile.md to confirm GitHub renders your tables and bullet lists as formatted Markdown.

Push rejected or authentication error?

If you see a message about authentication, GitHub may be prompting you to sign in. A browser window should open asking you to authorize VS Code. Click Authorize and try the push again.

If you see "rejected" because the remote contains work you don't have locally, run git pull --rebase first, then git push again.

help me fix a git push authentication or rejection error

✔️ Awesome, I've got everything!

Great. Confirm you've saved system-security-profile.md and that it appears on your GitHub repository page with all tables rendering correctly.

ⓧ I'd like to double check the full code

Scroll up and confirm your system-security-profile.md contains all of these sections in order:

  • System Identification table (7 attribute rows).
  • System Description paragraph mentioning 15,000 applications per month and PII.
  • System Boundary listing 5 components inside and 3 outside.
  • FIPS 199 Security Categorization heading.
  • Information Types Processed table (4 rows).
  • Impact Assessment table (Confidentiality MODERATE, Integrity MODERATE, Availability LOW).
  • Overall System Categorization statement showing MODERATE as the high-water mark.

Your system is defined, bounded, and categorized. Next up, you'll write the control implementation statements that document how the system meets (or fails to meet) specific NIST SP 800-53 security requirements.

Document Control Implementation Statements

You now have a categorized system, but no record of what security measures are actually in place.

Control implementation statements are the core deliverable of a System Security Plan. They describe exactly how each NIST SP 800-53 control is (or isn't) met for your specific system. This is what assessors review and what GTA's Office of Information Security produces for every GETS system.

In this step, get ready to:
  • Select 10 controls from the NIST SP 800-53 Rev 5 Moderate baseline.
  • Write implementation statements with status and narrative for each control.
  • Commit and push your work to GitHub.
Select the control baseline and create the file

Your FIPS 199 categorization determined that GCSP is a Moderate-impact system. This means you'll assess against the NIST SP 800-53 Rev 5 Moderate baseline.

You'll select 10 controls across 5 families that matter most for a citizen services portal handling PII.

  • In VS Code, create a new file called control-implementations.md in your repository folder.
  • Add the file header and your first two Access Control family statements by pasting the following:
# NIST SP 800-53 Rev 5 Control Implementation Statements

## System: Georgia Citizen Services Portal (GCSP)
## Baseline: Moderate
## Assessment Date: July 2026

---

## AC-2: Account Management

**Control Description:** The organization manages system accounts including establishing, activating, modifying, reviewing, disabling, and removing accounts.

**Implementation Status:** Partially Implemented

**Implementation Narrative:** Staff accounts are provisioned through Active Directory with role-based access tied to job function. Account creation requires supervisor approval via email. However, there is no automated process for periodic account review. Accounts of separated employees are disabled upon HR notification, but no regular audit confirms all inactive accounts are removed within the required 30-day timeframe. Citizen self-service accounts are created upon registration but have no inactivity timeout or automatic disable after 90 days of non-use.

---

## AC-6: Least Privilege

**Control Description:** The organization employs the principle of least privilege, allowing only authorized accesses necessary for users to accomplish assigned tasks.

**Implementation Status:** Implemented

**Implementation Narrative:** The system enforces role-based access control (RBAC) with four defined roles: Citizen (view/submit own applications), Case Worker (view/process assigned applications), Supervisor (approve determinations, manage case worker assignments), and System Administrator (full system access). Each role is mapped to minimum necessary permissions. Privileged access to the database and application servers requires a separate administrator account distinct from daily-use credentials. Access control lists are reviewed quarterly by the ISSO.

---

What does this structure do?

Each control implementation statement follows a consistent format that an assessor expects to see:

  • Control ID and Name identifies exactly which NIST control you're addressing.
  • Implementation Status gives the quick verdict: Implemented, Partially Implemented, or Not Implemented.
  • Implementation Narrative explains HOW the system meets (or fails to meet) the control in 2-3 sentences specific to your system.

Notice that AC-2 is marked Partially Implemented on purpose. The gaps you create here become your findings in the gap analysis step.

  • Save control-implementations.md with Ctrl+S.
  • You should see the file appear in your VS Code Explorer sidebar, and the editor shows your header plus two control blocks (AC-2 and AC-6).

File not showing in the sidebar?

Make sure you created the file inside your nist-800-53-risk-assessment folder, not outside it. Check the VS Code title bar to confirm you have the correct folder open.

help me find where my file was created

Write implementation statements for the remaining controls

You have 8 more controls to document across 4 additional families. Follow the same pattern: control ID, description, status, and a narrative that explains the specifics.

  • Add the Identification and Authentication family controls below your AC-6 entry:
## IA-2: Identification and Authentication (Organizational Users)

**Control Description:** The system uniquely identifies and authenticates organizational users.

**Implementation Status:** Partially Implemented

**Implementation Narrative:** Staff users authenticate via Active Directory using unique username and password. Authentication is required prior to any system access. However, multi-factor authentication (MFA) is not yet implemented for staff accessing the application. Staff currently authenticate with passwords only. An MFA solution has been approved for procurement but is not yet deployed. Citizen users authenticate with username and password; MFA is not required for citizen accounts.

---

## IA-5: Authenticator Management

**Control Description:** The organization manages system authenticators (passwords, tokens, certificates) including their issuance, maintenance, and revocation.

**Implementation Status:** Implemented

**Implementation Narrative:** Password policy enforces minimum 14-character length, complexity requirements (uppercase, lowercase, number, special character), 90-day maximum lifetime, and 12-password history. Account lockout occurs after 5 failed attempts. Temporary passwords issued for new accounts must be changed upon first login. Password policy is enforced through Active Directory Group Policy Objects for staff and application-level validation for citizen accounts.

---

Why is IA-2 only Partially Implemented?

The system authenticates users (good), but lacks multi-factor authentication for staff (gap). This is a realistic finding in government systems where MFA procurement takes months.

  • Save the file.
  • You should now see 4 control blocks in your file (AC-2, AC-6, IA-2, IA-5).
  • Add the Audit and Accountability family controls below IA-5:
## AU-2: Event Logging

**Control Description:** The organization determines that the system is capable of auditing organization-defined events.

**Implementation Status:** Implemented

**Implementation Narrative:** The system logs the following events: successful and failed login attempts, privilege escalation, account creation/modification/deletion, access to citizen PII records, benefit determination approvals, and system errors. Logs are generated by the web server (IIS logs), application server (.NET event logging), database server (SQL Server audit), and Active Directory. Logs include timestamp, user ID, event type, source IP, and outcome (success/failure).

---

## AU-6: Audit Record Review, Analysis, and Reporting

**Control Description:** The organization reviews and analyzes system audit records for indications of inappropriate or unusual activity and reports findings.

**Implementation Status:** Not Implemented

**Implementation Narrative:** While audit logs are generated (per AU-2), there is currently no process for regular review and analysis of audit records. Logs are stored on local servers but are not forwarded to a centralized SIEM or log management platform. No staff member is assigned responsibility for daily or weekly log review. Audit records are only examined reactively when an incident is reported. There is no automated alerting for suspicious patterns such as multiple failed logins, off-hours access, or bulk data exports.

---

What makes AU-6 a critical gap?

AU-2 generates the logs, but AU-6 is about actually reviewing them. A system that logs everything but never looks at those logs has a dangerous blind spot. This Not Implemented finding will become one of your highest-risk items in the gap analysis.

  • Add the Configuration Management family controls below AU-6:
## CM-2: Baseline Configuration

**Control Description:** The organization develops, documents, and maintains a current baseline configuration of the system.

**Implementation Status:** Not Implemented

**Implementation Narrative:** There is no documented baseline configuration for the GCSP system components. Server builds are performed ad hoc based on administrator knowledge rather than a documented standard. Configuration changes are not tracked against an approved baseline. There is no configuration management database (CMDB) or equivalent documentation recording the approved state of system components. This makes it impossible to detect unauthorized configuration changes or ensure consistency across environments.

---

## CM-6: Configuration Settings

**Control Description:** The organization establishes and documents mandatory configuration settings for IT products using security configuration checklists.

**Implementation Status:** Partially Implemented

**Implementation Narrative:** Some hardening has been applied to production servers (disabled unnecessary services, removed default accounts), but these settings are not formally documented in a security configuration guide. No DISA STIG or CIS Benchmark has been formally adopted as the configuration standard. Settings were applied based on administrator best judgment rather than an approved checklist. There is no process to verify that configuration settings remain in compliance over time.

---
  • Save the file.
  • Scroll through your file. You should now have 8 controls documented across 4 families (AC, IA, AU, CM).
  • Add the final two controls (Risk Assessment and System Communications) below CM-6:
## RA-5: Vulnerability Monitoring and Scanning

**Control Description:** The organization monitors and scans for vulnerabilities in the system and hosted applications.

**Implementation Status:** Not Implemented

**Implementation Narrative:** No vulnerability scanning tool is deployed for the GCSP environment. Neither the operating systems, web server, application code, nor database are subject to regular automated vulnerability scanning. The organization does not subscribe to vulnerability alerting services for the specific software versions in use. Patch management relies on ad hoc awareness of critical patches rather than systematic identification of all applicable vulnerabilities. The last known security scan was performed during initial deployment 18 months ago.

---

## SC-8: Transmission Confidentiality and Integrity

**Control Description:** The system protects the confidentiality and integrity of transmitted information.

**Implementation Status:** Implemented

**Implementation Narrative:** All citizen-facing communications are encrypted using TLS 1.2 or higher. The web server certificate is issued by a trusted Certificate Authority and is configured to reject connections using deprecated protocols (SSL 3.0, TLS 1.0, TLS 1.1). Internal communications between the web server and application server traverse an encrypted VPN tunnel within the agency network. Database connections use encrypted channels. Administrative access to servers requires VPN with AES-256 encryption.

Why mix statuses on purpose?

A real assessment never finds everything perfectly implemented. Your mix of 4 Implemented, 3 Partially Implemented, and 3 Not Implemented controls is realistic for a government system.

The gaps you've documented (AU-6, CM-2, RA-5, IA-2, AC-2, CM-6) become the raw material for your gap analysis and POA&M in the next steps.

  • Save control-implementations.md.
  • Scroll through the entire file from top to bottom. Count 10 control headings across 5 families: AC (2), IA (2), AU (2), CM (2), RA (1), SC (1).

✔️ Awesome, I've got everything!

Great. Double check you've saved your file with all 10 controls present.

ⓧ I'd like to double check the full code

Your file should contain these sections in order. Scroll through and confirm each is present:

  • File header (title, system name, baseline, date).
  • AC-2: Account Management (Partially Implemented).
  • AC-6: Least Privilege (Implemented).
  • IA-2: Identification and Authentication (Partially Implemented).
  • IA-5: Authenticator Management (Implemented).
  • AU-2: Event Logging (Implemented).
  • AU-6: Audit Record Review, Analysis, and Reporting (Not Implemented).
  • CM-2: Baseline Configuration (Not Implemented).
  • CM-6: Configuration Settings (Partially Implemented).
  • RA-5: Vulnerability Monitoring and Scanning (Not Implemented).
  • SC-8: Transmission Confidentiality and Integrity (Implemented).

Missing a control or seeing formatting issues?

Make sure each control section starts with ## (two hashes and a space) for the heading. Check that bold markers ** wrap the labels like Control Description, Implementation Status, and Implementation Narrative.

Each control should be separated by a line containing only --- (three dashes) to create a horizontal rule.

help me fix my Markdown formatting

Commit your progress to GitHub

You have two complete documents now: your system security profile and your control implementation statements. Time to push both to your GitHub repository.

  • Stage all your files by running this in the VS Code terminal:
git add .
  • Commit with a descriptive message by running:
git commit -m "Add system profile and control implementations"
  • Push to GitHub by running:
git push

Before you check the result, what do you expect to see on your GitHub repository page?

  • Open your repository on GitHub in your browser.
  • You should see both system-security-profile.md and control-implementations.md listed in the file list.
  • Click control-implementations.md to confirm GitHub renders all 10 control headings with their status badges.

Push rejected or authentication error?

If you see a permission denied error, GitHub may need you to authenticate. When prompted, sign in through the browser window that appears.

If the push is rejected because the remote contains work you don't have locally, run git pull --rebase first, then try git push again.

help me push my code to GitHub

You now have a documented record of 10 security controls with honest assessments of where the system falls short. Next up, you'll turn those gaps into a scored risk analysis that shows which problems are urgent and which can wait.

Conduct Gap Analysis and Score Risks

In the previous step, you documented 10 control implementation statements. Some are marked "Partially Implemented" or "Not Implemented." Right now those are just labels.

Without risk scoring, there's no way to know which gaps are urgent and which can wait. In this step, you'll turn raw findings into prioritized decisions using a likelihood x impact matrix. This is where your earlier FIPS 199 categorization work pays off.

In this step, get ready to:
  • Identify control gaps from your implementation statements.
  • Build a 5x5 likelihood x impact risk scoring matrix.
  • Rate each finding and produce a prioritized gap analysis document.
Identify gaps from your control statements

A gap analysis examines the distance between where your security controls are and where they need to be. Every control marked "Partially Implemented" or "Not Implemented" represents a gap that an attacker could exploit.

  • Open control-implementations.md in VS Code.
  • Review each control and identify every one that is NOT fully "Implemented."

You should find 6 controls with gaps:

  • AC-2 (Account Management) - Partially Implemented.
  • IA-2 (Identification and Authentication) - Partially Implemented.
  • AU-6 (Audit Record Review) - Not Implemented.
  • CM-2 (Baseline Configuration) - Not Implemented.
  • CM-6 (Configuration Settings) - Partially Implemented.
  • RA-5 (Vulnerability Monitoring and Scanning) - Not Implemented.

Why do some gaps matter more than others?

A missing MFA control on a system that handles 15,000 citizens' SSNs every month is a very different risk than undocumented configuration settings. Your FIPS 199 Moderate categorization tells you the potential damage is serious. The gap analysis adds the other dimension: how likely is it that someone exploits each weakness?

  • Create a new file called gap-analysis.md in your repository folder by right-clicking in the VS Code Explorer sidebar and selecting New File.
  • Add the document header and risk scoring methodology by pasting the following content:
# Gap Analysis - Georgia Citizen Services Portal (GCSP)

## Assessment Date: July 2026
## Assessor: [Your Name]
## System Impact Level: Moderate

---

## Risk Scoring Methodology

Risks are scored using a 5x5 Likelihood x Impact matrix. Likelihood considers how probable exploitation of the gap is given current threat landscape. Impact considers the damage if the gap is exploited, informed by the system's FIPS 199 categorization (Moderate).

### Risk Scoring Matrix

| Likelihood / Impact | Very Low | Low | Moderate | High | Very High |
|-------------------|----------|-----|----------|------|----------|
| Very High | Low | Medium | High | Critical | Critical |
| High | Low | Medium | High | High | Critical |
| Moderate | Low | Low | Medium | High | High |
| Low | Low | Low | Low | Medium | Medium |
| Very Low | Low | Low | Low | Low | Low |

### Risk Rating Definitions

| Rating | Description |
|--------|-------------|
| Critical | Immediate action required. Gap poses imminent threat of serious harm. |
| High | Action required within 30 days. Gap significantly increases risk exposure. |
| Medium | Action required within 60 days. Gap creates measurable risk that should be addressed. |
| Low | Action required within 90 days. Gap presents minimal risk but should be tracked. |

What does this methodology section do?

The 5x5 matrix maps two questions onto a single risk rating. The vertical axis asks "how likely is exploitation?" The horizontal axis asks "how bad is the damage?" Where those two answers intersect gives you a rating from Low to Critical.

The Risk Rating Definitions translate each rating into an action timeline. This is what leadership cares about: not the matrix itself, but how fast each gap needs to be fixed.

  • Save gap-analysis.md.
  • Check the file in VS Code. You should see the matrix table with 5 rows and 5 columns of risk ratings, plus 4 rating definitions below it.

Table looks broken or misaligned?

Markdown tables need the pipe characters (|) aligned on each row. If your table renders oddly, check that every row has the same number of | characters.

Help me fix my Markdown table formatting in gap-analysis.md

Build a risk scoring matrix and rate each finding

Now you'll write up each gap as a formal finding with a risk rating. For each one, you'll assess how likely exploitation is and what the impact would be, then look up the intersection on your matrix.

  • In gap-analysis.md, add the following Findings section header and first two findings below your Risk Rating Definitions table:

---

## Findings

### Finding 1: No Audit Record Review Process (AU-6)

| Attribute | Detail |
|-----------|--------|
| Control | AU-6: Audit Record Review, Analysis, and Reporting |
| Status | Not Implemented |
| Finding | Audit logs are generated but never reviewed. No SIEM, no assigned reviewer, no alerting. Malicious activity could persist undetected indefinitely. |
| Likelihood | High (attackers frequently target systems with no monitoring) |
| Impact | High (undetected compromise of PII for 15,000+ monthly applicants) |
| Risk Rating | HIGH |

---

### Finding 2: No Vulnerability Scanning (RA-5)

| Attribute | Detail |
|-----------|--------|
| Control | RA-5: Vulnerability Monitoring and Scanning |
| Status | Not Implemented |
| Finding | No vulnerability scanning tool is deployed. Known vulnerabilities in the system's software stack may exist unpatched. Last scan was 18 months ago at initial deployment. |
| Likelihood | High (unpatched systems are primary attack vector) |
| Impact | High (exploitation could lead to full system compromise and PII exposure) |
| Risk Rating | HIGH |

How did these findings get rated HIGH?

Both AU-6 and RA-5 have High likelihood AND High impact. On the 5x5 matrix, High x High intersects at "High" (one step below Critical). These are the most dangerous gaps because they combine a common attack vector with serious damage potential to 15,000+ citizens' PII.

  • Save gap-analysis.md and confirm you now see a "Findings" section with two finding tables, each rated HIGH.
  • Add Findings 3 and 4 below your second finding:

---

### Finding 3: No Baseline Configuration Documentation (CM-2)

| Attribute | Detail |
|-----------|--------|
| Control | CM-2: Baseline Configuration |
| Status | Not Implemented |
| Finding | No documented baseline configuration exists. Server builds are ad hoc. Cannot detect unauthorized changes or ensure environment consistency. Drift from secure state is undetectable. |
| Likelihood | Moderate (configuration drift is common without baselines) |
| Impact | Moderate (inconsistent configurations increase attack surface) |
| Risk Rating | MEDIUM |

---

### Finding 4: Multi-Factor Authentication Not Deployed for Staff (IA-2)

| Attribute | Detail |
|-----------|--------|
| Control | IA-2: Identification and Authentication |
| Status | Partially Implemented |
| Finding | Staff authenticate with password only. No MFA. Compromised credentials provide direct access to citizen PII. Solution has been approved but not deployed. |
| Likelihood | High (credential theft via phishing is extremely common) |
| Impact | High (staff accounts have direct access to PII database) |
| Risk Rating | HIGH |

Why is IA-2 rated HIGH when it's Partially Implemented?

Implementation status alone doesn't determine risk. IA-2 is only "partially" implemented because passwords work but MFA doesn't exist. The likelihood of credential theft via phishing is extremely high regardless of partial implementation. The impact is also high because a stolen password gives direct access to the PII database.

  • Save gap-analysis.md and confirm you now have 4 findings. You should see 3 rated HIGH and 1 rated MEDIUM.
  • Add Findings 5 and 6 below your fourth finding:

---

### Finding 5: No Automated Account Review (AC-2)

| Attribute | Detail |
|-----------|--------|
| Control | AC-2: Account Management |
| Status | Partially Implemented |
| Finding | No periodic automated review of active accounts. Inactive citizen accounts never expire. Separated employee accounts may persist beyond 30-day removal requirement. Orphaned accounts increase unauthorized access risk. |
| Likelihood | Moderate (account hygiene issues are common) |
| Impact | Moderate (orphaned accounts could be leveraged for unauthorized access) |
| Risk Rating | MEDIUM |

---

### Finding 6: No Formal Configuration Standards (CM-6)

| Attribute | Detail |
|-----------|--------|
| Control | CM-6: Configuration Settings |
| Status | Partially Implemented |
| Finding | Some hardening applied but not documented against any standard (DISA STIG, CIS Benchmark). No verification process. Settings based on administrator judgment rather than approved checklist. Compliance cannot be measured. |
| Likelihood | Low (current settings provide some protection) |
| Impact | Moderate (without standards, gaps in hardening may exist) |
| Risk Rating | LOW |

What makes Finding 6 only LOW risk?

CM-6 has Low likelihood because some hardening IS in place. The servers aren't wide open. Combined with Moderate impact, the matrix gives you LOW. This gap should still be tracked and resolved, but it's not urgent compared to the three HIGH findings.

  • Save gap-analysis.md.

Now add the summary section that gives leadership a quick count of findings by severity.

  • Add the following summary at the bottom of your file:

---

## Summary

| Risk Rating | Count |
|-------------|-------|
| Critical | 0 |
| High | 3 |
| Medium | 2 |
| Low | 1 |
| **Total Findings** | **6** |

The system's risk posture requires immediate attention to the 3 High-rated findings. The absence of audit monitoring (AU-6), vulnerability scanning (RA-5), and multi-factor authentication (IA-2) together create a scenario where the system could be compromised through known vulnerabilities or stolen credentials with no detection capability in place.

Why does the summary paragraph matter?

The table gives counts, but the narrative below it tells the story. It connects the three HIGH findings into a single threat scenario: exploit a known vulnerability, steal credentials because there's no MFA, and persist undetected because nobody reviews logs. That connected narrative is what makes a risk assessment actionable.

  • Save gap-analysis.md.

Before you look at the final tally, think about this: based on your 6 findings, how many do you expect to be rated Critical, High, Medium, and Low?

  • Scroll through your complete gap-analysis.md file.

You should see: 0 Critical, 3 High, 2 Medium, and 1 Low. The summary table at the bottom confirms this breakdown. Your gap analysis is complete.

Counts don't match?

Double-check that each finding's Risk Rating row matches the correct rating. Finding 1 (AU-6), Finding 2 (RA-5), and Finding 4 (IA-2) should all say HIGH. Finding 3 (CM-2) and Finding 5 (AC-2) should say MEDIUM. Finding 6 (CM-6) should say LOW.

Help me verify my risk ratings match my likelihood and impact scores

✔️ Awesome, I've got everything!

Great. Double check you've saved your file and scroll through to confirm you have the methodology section, all 6 findings, and the summary table.

ⓧ I'd like to double check the full code

Your gap-analysis.md file is long, so confirm these sections are present in order:

  • Document header (title, date, assessor, system impact level).
  • Risk Scoring Methodology with the 5x5 matrix table and Risk Rating Definitions table.
  • Findings section with 6 findings, each in its own table (AU-6, RA-5, CM-2, IA-2, AC-2, CM-6).
  • Summary table showing 0 Critical, 3 High, 2 Medium, 1 Low, 6 Total.
  • A closing narrative paragraph connecting the HIGH findings into a threat scenario.

Scroll up through the code blocks in this step to compare each section against your file if anything is missing.

You have a prioritized gap analysis with scored findings. Next up, you'll turn these findings into a tracked remediation plan with owners, deadlines, and resources.

Build the Plan of Action and Milestones (POA&M)

Your gap analysis identified 6 findings and scored each one, but right now those are just documented problems sitting in a file. Without a remediation plan, your assessment is incomplete.

The POA&M (Plan of Action and Milestones) turns findings into tracked action items with owners, deadlines, and resources. This is the document leadership reviews in status meetings. It also shows a hiring manager that you don't just find problems. You solve them.

In this step, get ready to:
  • Create a POA&M with tracked remediation items for each finding.
  • Write a professional README framing your repository for hiring managers.
  • Commit and push all files to GitHub.
Create the POA&M document

The POA&M table maps each gap finding to a specific remediation action, assigns responsibility, and sets a deadline based on risk severity. Higher-risk findings get shorter timelines.

  • Create a new file called poam.md in your repository folder.
  • Add the document header and the main POA&M table by pasting the following content:
# Plan of Action and Milestones (POA&M)

## System: Georgia Citizen Services Portal (GCSP)
## Date Created: July 2026
## System Impact Level: Moderate
## Prepared By: [[YOURNAME="your name"]]

---

| ID | Finding | Control | Risk | Remediation Plan | Responsible Party | Target Date | Resources Required | Status |
|----|---------|---------|------|-----------------|-------------------|-------------|-------------------|--------|
| GCSP-001 | No audit record review process | AU-6 | High | Deploy SIEM solution (evaluate Splunk, Elastic, or Azure Sentinel). Assign daily log review to Security Operations. Establish automated alerting rules for failed logins, off-hours access, and bulk data exports. | Security Operations Team | 30 days | SIEM licensing ($0 if open source), 1 FTE for daily review, training budget | Open |
| GCSP-002 | No vulnerability scanning | RA-5 | High | Procure and deploy vulnerability scanning tool (Tenable Nessus or OpenVAS). Establish weekly automated scans. Define patch prioritization SLA: Critical within 7 days, High within 14 days, Medium within 30 days. | Vulnerability Management Team | 30 days | Scanning tool license, scan infrastructure, remediation staff time | Open |
| GCSP-003 | MFA not deployed for staff | IA-2 | High | Complete deployment of approved MFA solution for all staff accounts accessing GCSP. Enforce MFA for VPN, application login, and privileged access. Conduct staff training on MFA enrollment. | Identity Management Team | 14 days | MFA solution (already procured), enrollment time, training materials | Open |
| GCSP-004 | No baseline configuration documentation | CM-2 | Medium | Document current approved configuration for all GCSP components (web server, app server, database, network devices). Adopt CIS Benchmarks as the configuration standard. Store baselines in version control. | System Administration Team | 45 days | Staff time for documentation, CIS Benchmark subscription (free for basic) | Open |
| GCSP-005 | No automated account review | AC-2 | Medium | Implement quarterly automated account audit using PowerShell scripts against Active Directory. Configure 90-day inactivity timeout for citizen accounts. Establish monthly reconciliation with HR separation reports. | Identity Management Team | 60 days | Scripting development time, HR coordination, account management tool | Open |
| GCSP-006 | No formal configuration standards adopted | CM-6 | Low | Formally adopt CIS Benchmarks for Windows Server, IIS, and SQL Server. Document current settings against benchmark. Implement quarterly compliance scanning to detect drift. | System Administration Team | 90 days | CIS Benchmark documentation, compliance scanning tool, staff training | Open |

What does this table do?

Each row maps directly to one of your gap analysis findings. The columns track everything leadership needs to see in a status meeting.

  • Target dates are driven by risk rating. High-risk items get 14-30 days. Medium gets 45-60 days. Low gets 90 days.
  • Responsible parties are assigned by function (who actually does the work), not by individual name.
  • The Status column starts as "Open" and tracks through to closure as remediation progresses.
  • Save poam.md.
  • Open the VS Code preview (Ctrl+Shift+V) to confirm the table renders with all 6 rows and 9 columns.

Table not rendering correctly in preview?

Make sure the separator row (the line with dashes and pipes) has the same number of columns as the header row. Each pipe character must align. If a cell's content contains a pipe character, escape it with a backslash.

Why isn't my Markdown table rendering in VS Code preview?

Now add the milestones schedule and completion criteria below the table. These sections show how remediation progress is tracked and when a finding can be officially closed.

  • Add the following content at the bottom of poam.md, below the main table:
---

## Milestones and Review Schedule

| Milestone | Target Date | Review Cadence |
|-----------|-------------|----------------|
| GCSP-003 MFA deployment complete | 14 days from start | Daily standup during deployment |
| GCSP-001 SIEM operational with alerting | 30 days from start | Weekly progress report to ISSO |
| GCSP-002 First vulnerability scan complete | 30 days from start | Weekly progress report to ISSO |
| GCSP-004 Baselines documented | 45 days from start | Bi-weekly checkpoint |
| GCSP-005 Account audit automated | 60 days from start | Monthly review |
| GCSP-006 Configuration standards adopted | 90 days from start | Monthly review |

## Completion Criteria

Each POA&M item is considered closed when:
1. The remediation action has been fully implemented
2. Evidence of implementation has been collected and stored
3. The control has been re-assessed and found Satisfied
4. The ISSO has reviewed and approved closure

Why include milestones and completion criteria?

The milestones table orders remediation by urgency (shortest deadline first), not by finding number. This tells leadership what gets done first and how often they'll get updates.

Completion criteria prevent premature closure. A finding isn't "done" just because someone deployed a tool. It's done when the control is re-assessed and an authorizing official signs off.

  • Save poam.md.
  • In the VS Code preview, scroll through the entire document. You should see the main POA&M table (6 rows), followed by a Milestones and Review Schedule table (6 milestones ordered by target date), followed by a numbered Completion Criteria list.

Missing the milestones section?

Make sure there's a blank line between the end of the main table and the --- separator. Markdown needs blank lines before and after headings and horizontal rules to render them correctly.

✔️ Awesome, I've got everything!

Great. Double check you've saved your file, then move on to writing the README.

ⓧ I'd like to double check the full code

Scroll up and confirm your poam.md contains these sections in order:

  • Document header (title, system name, date, impact level, prepared by).
  • Main POA&M table with 6 rows (GCSP-001 through GCSP-006), each with 9 columns.
  • Milestones and Review Schedule table with 6 entries ordered by target date.
  • Completion Criteria with 4 numbered requirements.
Write a professional README and push to GitHub

The README is the first thing a hiring manager sees when they click your GitHub repository link. It needs to immediately communicate what this project demonstrates and guide them to each artifact.

  • Open your existing README.md file in VS Code.
  • Select all the existing content (Ctrl+A) and replace it with the following:
# NIST 800-53 Risk Assessment Package - Georgia Citizen Services Portal

A fictional NIST SP 800-53 Rev 5 risk assessment demonstrating Governance, Risk, and Compliance (GRC) capabilities for a Georgia state agency system.

## Overview

This repository contains a complete risk assessment package for the Georgia Citizen Services Portal (GCSP), a fictional moderate-impact web application that processes citizen benefit applications. All content is fictional and was created as a professional portfolio exercise.

## Artifacts

| Document | Description |
|----------|-------------|
| [System Security Profile](system-security-profile.md) | System description, boundary, and FIPS 199 categorization |
| [Control Implementations](control-implementations.md) | NIST SP 800-53 Rev 5 control implementation statements |
| [Gap Analysis](gap-analysis.md) | Control gap findings with risk scoring matrix |
| [Plan of Action & Milestones](poam.md) | Tracked remediation plan with owners and timelines |

What does this section do?

The title and subtitle tell a recruiter at a glance what this repository is. The Artifacts table gives them clickable links to jump directly into any document. This is critical because hiring managers spend seconds scanning repositories, not minutes.

  • Now add the remaining sections below the Artifacts table in the same README.md file:
## Frameworks Referenced

- NIST SP 800-53 Rev 5 (Security and Privacy Controls)
- FIPS 199 (Standards for Security Categorization)

## Skills Demonstrated

- FIPS 199 system categorization
- NIST SP 800-53 Rev 5 control selection and assessment
- Security control implementation statement writing
- Gap analysis and risk scoring (likelihood x impact)
- POA&M development with remediation planning
- GRC documentation aligned to federal/state standards

## Disclaimer

All systems, agencies, personnel, and findings in this repository are entirely fictional. This project was created as a training and portfolio exercise to demonstrate GRC assessment capabilities.

Why include a disclaimer?

The disclaimer makes it immediately clear this is a portfolio exercise, not an actual government assessment. This protects you legally and signals to hiring managers that you understand the sensitivity of real assessment documents.

  • Save README.md.
  • Open the VS Code preview (Ctrl+Shift+V). You should see a formatted page with a title, overview paragraph, clickable artifacts table, frameworks list, skills list, and disclaimer.

Artifacts table links showing as plain text?

The links in the Artifacts table use relative paths (e.g. system-security-profile.md). They won't be clickable in VS Code preview, but they will work on GitHub once you push. Confirm the filenames in the links match your actual filenames exactly (case-sensitive).

Why aren't my Markdown links working in VS Code preview?

✔️ Awesome, I've got everything!

Great. Make sure both files are saved, then continue to push everything to GitHub.

ⓧ I'd like to double check the full code

Scroll up and confirm your README.md contains these sections in order:

  • Title heading and one-sentence subtitle about GRC capabilities.
  • Overview paragraph stating this is a fictional portfolio exercise.
  • Artifacts table with 4 linked documents.
  • Frameworks Referenced listing NIST SP 800-53 Rev 5 and FIPS 199.
  • Skills Demonstrated with 6 bullet points.
  • Disclaimer stating all content is fictional.

Now commit all your work and push it to GitHub. This single commit captures the gap analysis from the previous step, the POA&M, and the README together.

  • Stage, commit, and push all files by running these commands in the VS Code terminal:
git add .
git commit -m "Add gap analysis, POAM, and README"
git push

Before you check GitHub, what do you expect to see on your repository page now that the README has been pushed?

  • Open your browser and navigate to your repository on GitHub.
  • You should see your formatted README rendered on the repository homepage, complete with the title, overview, clickable artifacts table, and all your listed skills.
  • Click one of the artifact links in the table (e.g. Plan of Action & Milestones) to confirm it opens the correct file.

Push rejected or authentication failed?

If you see an authentication error, GitHub may be prompting you to use a Personal Access Token instead of a password. Go to GitHub Settings, then Developer settings, then Personal access tokens to generate one. Use that token as your password when prompted.

If the push is rejected because of remote changes, run git pull --rebase first, then try git push again.

Why is my git push being rejected?

Your risk assessment package is complete. You now have a live GitHub portfolio with a system profile, control implementations, gap analysis, and a POA&M. This demonstrates the full GRC assessment lifecycle that a hiring manager can click through and evaluate.

Secret mission

Write an Executive Risk Brief

The GTA Cybersecurity Specialist 2 role requires communicating cyber risk to all levels of management, including non-technical leadership. Can you translate your technical findings into a one-page executive brief that a Deputy Director would actually read?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally with a free GitHub repository, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Local nist-800-53-risk-assessment project folder with all Markdown files.
  • GitHub repository nist-800-53-risk-assessment (public).
  • GitHub account (if created for this project).
  • Visual Studio Code (installed).
  • Git (installed via winget).

Keep everything running

No action needed. Choose this if you plan to continue building on this portfolio or want to keep it visible for hiring managers.

  • Your GitHub repository stays public and accessible via your profile.
  • Your local folder remains on your machine for future edits.
  • VS Code and Git remain installed for future projects.

Pause - I'll come back to this later

There are no running processes or paid services to shut down. Everything is already paused by default.

  • Your GitHub repository remains available at no cost whenever you return.
  • Your local files stay on disk until you decide to remove them.
  • If you want to free up disk space without losing work, you can delete the local folder since everything is already pushed to GitHub. You can re-clone later.

Delete - I don't want to use this again

Remove all project resources and start fresh. Only do this if you are sure you no longer need the portfolio repository.

  • Delete the local project folder by opening PowerShell and running the command below.
Remove-Item -Recurse -Force nist-800-53-risk-assessment

Run this from the parent folder

Make sure you are in the folder that contains nist-800-53-risk-assessment before running this command. If you cloned it to your Desktop, run cd ~/Desktop first.

  • Delete the GitHub repository by going to your nist-800-53-risk-assessment repository page on GitHub.
  • Click the Settings tab at the top of the repository.
  • Scroll to the bottom of the page to the danger zone and delete the repository. GitHub will ask you to confirm by typing the repository name.
  • Delete your GitHub account (only if you created it solely for this project). Go to your GitHub account settings and look for the account deletion option.
  • Uninstall Git by running this command in PowerShell:
winget uninstall --id Git.Git
  • Uninstall VS Code by pressing the Windows key, typing Add or remove programs, selecting it, finding Microsoft Visual Studio Code in the list, and clicking Uninstall.

Nice Work!

Nice Work!

Nice work! You've just built a professional NIST SP 800-53 risk assessment package and published it to GitHub as a live portfolio artifact.

You've learned how to:

  • Performed a FIPS 199 security categorization and wrote control implementation statements for 10 NIST SP 800-53 Rev 5 controls across multiple families.
  • Conducted a gap analysis with a likelihood x impact risk scoring matrix and prioritized findings by severity.
  • Produced a Plan of Action and Milestones (POA&M) with tracked remediation items, responsible parties, and timelines that leadership can review in status meetings.
  • Secret Mission: Translated technical control findings into an executive risk brief written in plain business language for non-technical leadership.

Ready to quiz yourself?