It Dojo

The Implement step is where RMF packages start to diverge from reality, and it usually happens quietly.

Categorize and Select are paperwork exercises with paperwork outputs. Implement is the first step where something has to actually change on a system. That handoff is where the gap opens.

The most common failure is an implementation statement that describes intent rather than configuration. "Access is restricted to authorized personnel" is not an implementation. It is a restatement of the control. An assessor reading it has no idea what to go look at, and neither will the person who inherits the system from you.

What a usable implementation statement does:

It names the mechanism. Not "the system enforces password complexity" but which policy object, on which system, enforcing which setting. If someone has to open a console to verify it, tell them which console.

It matches what is actually deployed. Statements written from the design document instead of the running system are the single biggest source of assessment findings I see. Write them after implementation, not before, or plan to rewrite them.

It accounts for inheritance honestly. If you are inheriting a control from a common control provider or a cloud service provider, say so, name the provider, and be clear about what portion remains yours. Partial inheritance that gets documented as full inheritance is a gap nobody discovers until it matters.

It survives the person who wrote it. You will not be in the room for every question. The statement has to answer on your behalf.

The teams that do Implement well are not doing anything clever. They are documenting what they actually built, in enough detail that someone else can verify it. That is the whole trick, and it is why Assess goes smoothly for them and painfully for everyone else.

Plenty of people earn Security+ and then stall, unsure what to certify next. The honest answer is that there isn't one right next step. There's a right next step for your role, and choosing by your DoD 8140 work role beats chasing whatever cert is popular.

A few common paths. If you're moving toward hands-on defensive work in a SOC or analyst seat, CySA+ is the natural follow-on. It picks up where Security+ leaves off and goes deep on detection, analysis, and response. If you're heading toward senior or enterprise-level security decisions, CASP+, now SecurityX, is the more advanced technical track. If your work is moving into the cloud, a cloud-focused certification, whether vendor-neutral or tied to your agency's platform, will serve you better than another general security cert.

The tactic is simple but underused: look at the work role you're actually in or aiming for, check what 8140 maps to it, and let that drive the choice. A certification that lines up with your role compounds, because the studying reinforces the job and the job reinforces the studying. One chosen at random just sits on your resume.

Don't pick your next cert by momentum. Pick it by where you're going.

Here's a pattern that should worry federal IT leaders more than it does. Agencies invest in developing their people, the person earns the certifications, their skills and market value jump, and then they leave. The training works exactly as intended, and the organization still loses.

It's tempting to read this as a pay problem, and compensation is part of it. But in a lot of the conversations I have, money isn't the first thing people raise. They talk about wanting to use the skills they just built, about growth that stops the moment they certify, and about work that doesn't change even after their capability does. Someone who earns a demanding certification and then goes back to the exact same tasks starts looking around, not because they're disloyal, but because they can see a ceiling.

The agencies that keep their talent treat certification as a beginning, not a finish line. They give newly skilled people work that stretches them, a visible path forward, and a reason to believe the next few years will look different from the last. That costs intention more than it costs budget.

Developing people and retaining them are the same project. If the growth stops when the training ends, the retention problem is already in motion.

The Select step is where an RMF package either gets right-sized or sets itself up for months of unnecessary work. It's the point where you take your categorization and turn it into the specific set of controls the system will implement. Done well, it produces a defensible, appropriately scoped baseline. Done carelessly, it leaves you assessing controls you don't need or missing ones you do.

Selection starts from the baseline your categorization drives, but the real skill is in tailoring. Tailoring means adjusting that baseline to fit your system's actual mission, environment, and architecture, applying overlays where they fit, and documenting every adjustment with a rationale. Overlays matter especially in the national security and DoD space, where CNSSI 1253 and mission-specific overlays shape what the baseline should actually be.

The two failure modes are mirror images. Over-tailoring strips out controls to make the package smaller, and it comes back to bite you at assessment and authorization. Under-tailoring keeps every control in scope regardless of relevance, burning effort assessing things that don't apply to your system. Both come from treating Select as a checklist instead of a deliberate, documented engineering decision.

Tailor with rationale, apply overlays correctly, and the assessment that follows becomes far more manageable.

Federal security operations are increasingly built on Microsoft tooling, and the teams running them need people who can actually operate it, not just understand it in theory. SC-200 is the certification built for that role.

SC-200 is the Microsoft Security Operations Analyst certification. It's focused and hands-on, centered on detecting, investigating, and responding to threats using Microsoft Sentinel, Microsoft Defender, and the broader Microsoft security stack. This is day-to-day SOC work: triaging alerts, hunting threats, configuring analytics rules, and managing incidents inside the tools your environment actually uses.

For federal teams operating in Microsoft and Azure Government environments, the relevance is direct. As more agencies consolidate their security operations onto Sentinel and Defender, the demand for analysts who can run those platforms well keeps climbing. SC-200 validates exactly that capability, and it carries DoD 8140 value for relevant analyst roles.

This is a cert for people doing or moving into SOC work in a Microsoft-centric environment. If that's your team, SC-200 turns platform familiarity into demonstrated, certifiable skill.

At IT Dojo, we deliver SC-200 live and instructor-led, built around the federal SOC and Azure Government context. Visit itdojo.com or reach out at [email protected].

Federal teams moving into AWS GovCloud ask me the same thing constantly: where do I start? There are a lot of AWS certifications, and it's easy to either aim too low and waste time or aim too high and get discouraged. The right entry point depends on your role.

If you're new to AWS or you sit on the business, compliance, or program side, start with Cloud Practitioner. It builds the shared vocabulary and the mental model of how AWS services, billing, and security responsibilities fit together. It's foundational by design, and it makes every conversation with your technical team more productive.

If you're going to actually design and build in AWS, you can often skip past Cloud Practitioner and target Solutions Architect Associate instead. It's more demanding, but it's the cert that maps to real architecture and security decisions, and it respects the time of someone who's already technical. Starting too low here just delays the learning that matters for your role.

For GovCloud specifically, remember that the fundamentals are the same as commercial AWS, with the compliance and isolation overlay layered on top. Learn the core services and the shared responsibility model first, then apply the federal context.

Match the cert to the role, and you'll move faster.

Splunk is only as useful as the searches you build on top of it. I've watched SOC teams sit on a goldmine of data and still miss things, because their searches and dashboards were tuned to produce volume rather than signal. The tool isn't the bottleneck. How you query it is.

A few habits separate analysts who get value from Splunk from those who drown in it. First, start from the question, not the data. Decide what behavior you're trying to surface, then build the search to answer it, instead of scrolling through events hoping something jumps out. Second, narrow aggressively. Tight time ranges, specific indexes, and filtered fields make searches faster and results more meaningful. Third, build dashboards around decisions, not around everything you can plot. A dashboard that shows ten things a person can act on beats one showing fifty they'll ignore.

The same applies to alerting. An alert that fires constantly trains people to ignore it, which is worse than no alert at all. Tune for the behavior that actually warrants a human response.

The analysts who master this stop thinking of Splunk as a place to search and start thinking of it as a place to ask sharp questions. That shift is where the real threat-hunting value lives.

There's a pattern I see across federal cloud migrations, and it's worth naming. The projects that stall rarely stall on technology. They stall on people. The platforms work. The skills to secure and operate them are what's missing.

Agencies can stand up cloud environments quickly. What takes longer is building a workforce that understands cloud security at a level deep enough to make real decisions: how identity and access work in the cloud, how to configure platform protections correctly, how to monitor environments that look nothing like the on-prem systems people trained on, and how to map all of it back to the controls an authorization depends on. When that understanding is thin, teams either move too slowly out of caution or move too fast and create risk they can't see.

The uncomfortable truth is that cloud security expertise can't be bought as quickly as cloud capacity. It has to be built in your existing people, the ones who already understand your mission and your systems. That's a training and development problem more than a procurement problem, and treating it that way is what separates migrations that succeed from the ones that quietly drag.

The agencies pulling ahead are the ones investing in their people's cloud security skills on purpose, before the migration forces the issue.

The Categorize step sets the trajectory for an entire RMF effort, and getting it wrong is expensive in both directions. Categorize too high and you burden the system with controls it doesn't need. Categorize too low and you under-protect it and invite trouble at assessment time. Yet this step often gets rushed because it happens before the visible security work begins.

Categorization rests on understanding the information types your system handles and the impact to confidentiality, integrity, and availability if that information is compromised. FIPS 199 gives you the high, moderate, low impact framework, and for national security systems CNSSI 1253 guides how you apply it. The high-water mark concept matters here: a single high-impact information type can drive the overall categorization, so you need an accurate inventory of what the system actually processes, stores, and transmits.

The mistake I see most is categorizing from assumption rather than from a real analysis of information types and mission impact. Slow down on this step. Document why each impact level is what it is, and tie it to the actual data and mission. Everything downstream, control selection, assessment scope, and the authorization decision, inherits from this choice.

Get Categorize right and the rest of the process rests on solid ground.

Federal teams are building software faster than ever, with CI/CD pipelines pushing changes continuously. The problem is that security often stays bolted on at the end, treated as a gate to clear rather than a discipline built into the process. DevSecOps is the correction, and it's a skill set worth investing in deliberately.

DevSecOps Foundation gives teams a shared language and framework for integrating security throughout the development lifecycle rather than at the finish line. It covers how security fits into culture, automation, and the pipeline itself, so that testing, compliance checks, and risk management happen continuously instead of in a last-minute scramble before a release.

For federal organizations, this matters twice over. You get the obvious benefit of catching security issues earlier and cheaper. And you get a development process that produces the evidence and consistency that authorization and continuous monitoring depend on, instead of fighting your own pipeline at ATO time.

This is a foundation-level credential, so it works well for whole teams: developers, operations staff, security people, and the managers who connect them. Getting everyone on the same page is often where the real value shows up.

At IT Dojo, we deliver DevSecOps Foundation live and instructor-led, built around the federal delivery context. Visit itdojo.com or reach out at [email protected].