RMFInsider

Your first 90 days as a new ISSO will not look like the job description on the requisition. Nobody hands you a syllabus. You get a badge, a laptop, and login credentials to systems you’ve never touched, and the assumption is that you’ll figure out which authorizations are expiring, which control implementations are fiction, and which POA&Ms have been quietly aging since the last ISSO left. This is what the first 90 days actually look like, broken into the stretches that matter, plus the mistakes that quietly cost new ISSOs their credibility in year one.

Nobody is going to hand you this timeline on day one, either. Program managers assume you already know it, and the ISSO you’re replacing is usually gone before you can ask. So treat the next four sections as the onboarding plan you should have gotten in writing, organized around the four windows that actually structure a new ISSO’s first quarter: accounts and relationships, system inventory, documentation reality, and your first real work product.

Window	Primary focus	What you should have by the end of it
Days 1–10	Accounts, access, relationships	eMASS and ACAS access requested; first meetings with AO, ISSM, SCA on the calendar
Days 11–30	System inventory	Your own tracker of every package, its categorization, and its ATO expiration date
Days 31–60	SSP reality check	Every SSP read; a documented list of where it diverges from scan and STIG evidence
Days 61–90	First real work product	One POA&M item driven to a milestone; one full ConMon cycle submitted

The First 90 Days as an ISSO Start Here: Days 1–10 (Accounts, Access, and Who to Meet)

The first ten days are almost entirely about access, and access is almost entirely about waiting. You need an eMASS account tied to the packages you’re inheriting, a login to your organization’s ACAS scanning console so you can pull vulnerability data yourself instead of asking someone else for it, and read access to wherever your System Security Plans, POA&Ms, and Security Assessment Reports actually live — usually a SharePoint site or shared drive nobody has cleaned up in years. Submit every access request on day one, even the ones that feel premature. Account provisioning is the single biggest bottleneck in a new ISSO’s first two weeks, and the tickets you don’t file on day one are the ones still open on day twenty.

While those tickets sit in a queue, spend the dead time on people, not paperwork. Get time on the calendar with your Authorizing Official, your ISSM, and the Security Control Assessor or SCA-V assigned to your systems. Ask each of them the same question: what’s the one thing keeping you up at night about this system? Their answers will tell you more about the real risk posture than any SSP will in your first month. If there’s an outgoing ISSO or a contractor who covered the role in the interim, get on their calendar before they disappear — they’re the fastest path to the informal knowledge that never made it into writing. If eMASS itself is new to you, this eMASS primer for new ISSOs is worth reading before your account even goes live, so you’re not learning the interface and the job at the same time.

Expect facility logistics to eat more of week one than you’d like. A badge that doesn’t open the right doors yet, a CAC or PIV certificate that hasn’t fully propagated to every system, and a help desk ticket queue that treats your account requests like any other user’s — these are normal, not a sign you’re behind. What separates ISSOs who hit the ground running from ones who lose a month is whether they used the downtime productively. Sitting on a laptop waiting for access is wasted time; sitting in a meeting with your ISSM asking what’s actually broken is not.

Days 11–30: Inventory Your Systems and Their ATO Clocks

Once you’re inside eMASS, build your own inventory before you trust anyone else’s. For every system you’re assigned, record the package name, the categorization from the Categorize step of the RMF process, the current authorization status, and — most importantly — the ATO expiration date. Nobody hands new ISSOs a clean list of this. You build it yourself, in a spreadsheet, cross-referenced against what eMASS actually shows, because eMASS records and whatever tracking spreadsheet your predecessor left behind disagree more often than anyone wants to admit.

This window is also when you find the systems nobody has been watching. It happens more than it should: a system with an ATO that expired months ago and nobody flagged it, because the ISSO who owned it moved on and the gap just sat there. Finding that in week three is a good outcome. Finding it in month eight, after an assessor finds it first, is not. If your organization’s eMASS records feel incomplete, or you’re not sure what a fully built-out package should even contain, the complete eMASS guide walks through what a healthy ATO package looks like end to end.

While you’re building the inventory, note the categorization for each system too — its impact level for confidentiality, integrity, and availability, set during the Categorize step of the RMF process. This matters beyond trivia: it determines which control baseline applies, and mismatched categorization is one of the more common findings an assessor turns up on a system nobody’s re-checked since it was first stood up. If a system’s mission changed since its last categorization but its paperwork didn’t, flag it now rather than letting an assessor flag it later.

Days 31–60: Read Your SSP and Find the Lies in It

Every System Security Plan you inherit was written by someone, at some point, under some deadline, and it says what that person needed it to say to get the package through Authorize. Your job in this stretch is to read every SSP for your systems cover to cover and start checking its claims against reality. If the SSP says patching is centrally managed and automated, go verify that with the system administrator — is it actually automated, or does someone remote into a dozen servers manually every month and call it managed? If it claims full disk encryption, ask to see it enabled on an actual endpoint, not just described in a paragraph.

Pull the latest SCAP scan results and STIG checklists — the CKL files — for each system and compare open findings against what the SSP claims is implemented. A control marked “implemented” with a CAT I finding sitting open in the exact same area is not implemented. It’s aspirational. This isn’t about catching anyone in a lie; most SSP drift happens because systems change faster than documentation does. But you can’t fix drift you haven’t found, and nobody else is going to find it for you. Keep a running list of every discrepancy you turn up here — you’ll use it in the next stretch.

Don’t skip the sections of the SSP that feel like boilerplate. Contingency planning, incident response procedures, and media protection language get copy-pasted between systems more than any other part of an SSP, which means they’re also the sections most likely to describe a process that was never actually implemented on your specific system. Ask whoever owns incident response for that system to walk you through it in practice, not in theory. If the answer is vague, that’s your next discrepancy for the list.

Days 61–90: Work Your First POA&M and Your First ConMon Cycle

By day 60 you should have a documented list of gaps between what the SSP claims and what’s actually true. Turn the most significant ones into your first POA&M items, or update existing POA&Ms that were written vaguely enough to mean nothing. Pick one — ideally the oldest or highest-severity item sitting untouched — and drive it to an actual milestone: a scheduled remediation date, a documented risk acceptance, or a closed finding with real evidence attached. New ISSOs who wait for the “right” POA&M to start with never actually start.

This window is also when you’ll run your first continuous monitoring cycle: pulling current ACAS scan data, confirming STIG compliance status, and packaging the ConMon deliverable your organization’s cadence requires, whether that’s monthly or quarterly. If you don’t already have a repeatable routine for this, a continuous monitoring checklist will save you from rebuilding your process from memory every single cycle.

Treat this first cycle as the one you’ll be judged against for every cycle after it. If you cut corners on your first ConMon submission because the deadline snuck up on you, that’s the standard your ISSM and AO will expect you to maintain — or worse, the standard they’ll assume is normal until an assessment proves otherwise. Build the habit now, even if it takes longer than it should the first time through.

The Five Mistakes New ISSOs Make

Watching new ISSOs come up through their first 90 days, the same five mistakes show up over and over:

• Trusting the SSP instead of the scan data. The SSP tells you what someone hoped was true when it was written; ACAS and your STIG checklists tell you what’s true today.
• Not tracking ATO expiration dates independently of eMASS. Systems fall out of authorization while everyone assumes someone else is watching the clock.
• Treating POA&Ms as paperwork instead of commitments. An open POA&M with no real remediation plan behind it is a liability, not documentation.
• Avoiding the AO and ISSM relationship until something goes wrong. The first real conversation with your AO should never be the one where you’re explaining an expired authorization.
• Learning eMASS, ACAS, and STIG Viewer for the first time during an actual assessment. Learn the tools in the quiet weeks, because there won’t be quiet weeks once an SCA is on site.

What “Good” Looks Like at Day 90

At 90 days, good looks like this: you know every system you own and its ATO expiration date without opening eMASS to check. You’ve read every SSP and have a documented list of where it diverges from reality. You have at least one POA&M item you personally drove toward closure, and you’ve submitted one full continuous monitoring cycle start to finish. Your AO, ISSM, and SCA know your name — and know you as someone who flags problems early, not someone who explains them after the fact. That reputation, once you’ve earned it, is the actual job.

If you want a single reference to keep next to your inventory spreadsheet while you build all of this out, the RMF Checklist covers the same Prepare-through-Monitor lifecycle in a format built for exactly this stretch of the job.