RMFInsider

A GRC home lab is not a rack of appliances. It is a practice authorization package: invent a small fictional system, categorize it, select a control baseline, write implementation statements, STIG one virtual machine, open two POA&M items, write a short risk assessment, and put the set in a folder a hiring manager can read in ten minutes. Everything you need is public: the NIST 800 series, the 800-53 control catalog, DISA STIGs and STIG Viewer from the DoD Cyber Exchange. A laptop with 16 GB of RAM and a free hypervisor covers the technical part. The output is what interviewers rarely see from a career changer: evidence you have produced RMF artifacts, not evidence you watched a course about them.

Ground rules before you touch anything

Three rules, and the first is not negotiable. Nothing from a real workplace goes into a portfolio: no system names, no diagrams, no scan output, no screenshots of a production console, no controlled unclassified information, and nothing you wrote on the clock for an employer or customer. A hiring manager who watches you present someone else’s SSP has learned the wrong thing about you.

Second, you will not be working in eMASS. Access requires a sponsored account tied to a real organization and a CAC to authenticate, and there is no public demo instance. That is fine: the artifacts are the skill and eMASS is the filing cabinet. Build everything in a word processor and a spreadsheet, and know the tool by name for the interview. If a stranger offers you a login to theirs, that is not mentorship, that is a reportable incident.

Third, label the system as fictional in the header of every document: “Practice system, fictional, prepared for portfolio purposes.” One line, and nobody has to wonder where the content came from.

The build sequence

This is the order I would use, and it runs eight to twelve evenings. Do not skip ahead to the STIG part because it feels like the technical one; categorization drives everything downstream.

• Invent the practice system and write a one page description with the boundary in words.
• Categorize it: pick information types, set confidentiality, integrity and availability, take the high water mark.
• Select the matching baseline from the public NIST SP 800-53B baselines and tailor a few controls with written rationale.
• Build the virtual machine your system’s server represents and harden it against the applicable STIG.
• Run the checklist in STIG Viewer 3.x, save the .ckl, and record open findings with severity.
• Write 8 to 10 implementation statements matching what you configured.
• Open two POA&M items from those findings, with milestones and dates.
• Write a two page risk assessment covering those findings.
• Assemble the package with an index and a version date.

Step 1: invent the system, then describe it like it exists

Keep it small and boring. Mine is a practice system I call the Volunteer Hours Tracker, a fictional internal web application for a fictional nonprofit: one Linux application server, one database, twelve staff accounts, volunteer names and email addresses stored, no payment data, no internet exposure, backed up nightly. That is enough surface to touch ten control families honestly. A fictional enterprise with fourteen subsystems is not more impressive, just unfinishable.

The system description is the artifact everything else references, so write it properly: purpose, users and roles, components inside the boundary, what connects in and out, where the data lives, and who the notional system owner is. Describe the boundary in words and a component list rather than drawing something elaborate. For the full shape of the document this grows into, the walkthrough of how to write a system security plan step by step shows what sections a real SSP carries, and your practice version can be a lighter subset of the same outline.

Step 2: categorize with FIPS 199

FIPS 199 gives three impact levels (low, moderate, high) across confidentiality, integrity and availability, and the overall categorization is the high water mark. NIST SP 800-60 Volume 2 lists information types with provisional impact levels, which is how you avoid guessing. For the Volunteer Hours Tracker I documented volunteer contact information and internal program records, set confidentiality moderate because personally identifiable information is present, integrity moderate because falsified hour totals would misstate program reporting, and availability low because a two day outage is an inconvenience. The high water mark makes it a moderate system.

Write the rationale in two or three sentences per objective and date it. That paragraph is the point of the exercise, because in an interview you are asked why, not what. Note in the document that national security systems in DoD categorize under CNSSI 1253 rather than FIPS 199 alone, and that a real categorization is approved by the system owner and authorizing official, not the analyst who drafted it. That line signals you know who owns the decision.

Step 3: select and tailor a baseline

Pull the NIST SP 800-53 Rev 5 catalog and the SP 800-53B baselines, both public downloads, and take the moderate baseline. Do not print it. Build a spreadsheet with one row per control: identifier, name, implementation status, tailoring note. Then tailor five to ten controls and write the reason in the row: not applicable because the system has no wireless component, satisfied by a notional common control from the hosting environment, scoped down because there are no mobile devices.

Tailoring with written rationale separates somebody who has read about RMF from somebody who has done it, and every assessor I have worked with reads the rationale before the status. Keep it honest: “planned” with a date beats “compliant” you cannot demonstrate.

Step 4: write 8 to 10 implementation statements

Write real statements for controls you configured on the virtual machine. Ten is plenty: AC-2 account management, AC-7 unsuccessful logon attempts, AU-2 event logging, CM-6 configuration settings, CP-9 system backup, IA-2 identification and authentication, IA-5 authenticator management, RA-5 vulnerability monitoring, SC-8 transmission confidentiality, SI-2 flaw remediation. Each statement says who does the thing, on what, how it is configured, how often, and where the evidence lives.

A weak statement says the system enforces password complexity in accordance with policy. A usable one says local accounts on the practice server are managed by the notional system administrator, creation requires documented approval from the system owner, accounts inactive for 35 days are disabled by a scheduled job, and the evidence is a monthly account listing export. Same control, and only one survives an assessor asking for proof. The mechanics, including writing to the assessment procedures rather than the control title, are in how to write control implementation statements, and the format transfers directly to a real package.

Step 5: run a STIG checklist against a hardened VM

Install a hypervisor (VirtualBox, Hyper-V, whatever your laptop supports) and build one virtual machine representing your system’s server: Ubuntu Server or Windows Server, whichever you have a STIG for. From the DoD Cyber Exchange public STIG library, download the STIG for that operating system and the current release of STIG Viewer 3.x, plus the SCAP content if you want automated results to compare against manual review. Check the release version on the site rather than trusting a blog post, including this one, because STIG releases change quarterly.

Then work in the order that teaches you something: create the checklist in STIG Viewer and review it unhardened, so you see what failure looks like. Fix twenty or thirty findings by hand, documenting each change, then re-run and save the .ckl. Leave three or four findings open on purpose, because an all-green checklist proves you clicked “not a finding” while honest open items prove you understand severity. Note which are CAT I, CAT II and CAT III. For the working sequence and the evidence each step produces, the ISSO checklist for applying STIGs is the version of this I use at work.

Step 6: two POA&M items and a short risk assessment

Take two open findings off your own checklist and write them up as POA&M entries. Each needs a plain language weakness description, the source (your STIG review, dated), the affected control identifier, a severity, a responsible party, an estimated resource requirement, a scheduled completion date, and milestones with dates. Write milestones somebody could verify: test the change in the lab by one date, apply it by another, re-scan and provide the .ckl by a third. Vague milestones are the top reason POA&M items slip, in a practice package as much as a real one.

Then write two pages of risk assessment in the spirit of NIST SP 800-30: for each open finding, the threat source and event, the vulnerability, the likelihood, the impact against your notional mission, the resulting risk level, and either a mitigation or a recommendation to accept. Say plainly that accepting risk is the authorizing official’s call, not yours.

Package it, and use it in the job search

Assemble one folder of PDFs with a one page index listing each artifact, its version and date, plus two sentences on the fictional system. Put it somewhere you can share in a sentence: a public repository, a portfolio page, or a single merged PDF. Name it “Practice RMF Package, moderate system, 2026” so nobody has to ask whether it is real work. What each artifact tells the reader:

• System description: you can define a boundary and describe components without hand waving.
• Categorization memo: you can apply FIPS 199 and defend a rationale, which is the decision new analysts get wrong.
• Control selection spreadsheet: you know baselines are tailored, not copied, and you write down why.
• Implementation statements: you write to evidence rather than policy language, the skill that fills a real SSP.
• STIG checklist with honest open findings: you have touched DISA content and understand CAT severity.
• POA&M entries: you can turn a finding into a dated plan with milestones somebody can verify.
• Risk assessment: you can express risk in mission terms and you know who accepts it.

Add a one paragraph lessons learned at the end: what surprised you, what you would categorize differently, which control was hardest to write. It reads as judgment, and judgment is the thing nobody fakes in a second interview.

Put one line in the resume experience section, not the hobby section: “Built a practice RMF package for a fictional moderate impact system: FIPS 199 categorization, tailored 800-53 moderate baseline, 10 control implementation statements, STIG checklist with 4 open findings, 2 POA&M items and a risk assessment.” It uses the words the job posting uses, which matters to the screening system and the human both, and it hands the interviewer something concrete to ask about.

The project is also the cheapest proof that a GRC path is realistic for you, and it pairs with the other work in the guide to cybersecurity portfolio projects that actually get people hired. If you are still deciding whether GRC is the lane, the GRC analyst route to six figures lays out the money and the ceiling. Then build the package, because the reader who does this by Thanksgiving interviews in January with artifacts in hand, and the reader who bookmarks it interviews with a certificate. If you want the whole sequence of cert, project and interview mapped out, that is what Zero to Hired covers.