FISMA RMF Step 3: Implement Security Controls

I still remember the look on the project manager's face when I told him we'd need to implement 421 security controls for their moderate-impact federal system. "Four hundred and twenty-one?" he repeated, his voice barely above a whisper. "That's... that's impossible."

Three months later, that same PM was presenting their implementation success story at a federal cybersecurity conference. What changed? They stopped thinking of controls as checkboxes and started thinking of them as building blocks for a secure system.

After spending over a decade implementing FISMA controls across dozens of federal agencies—from small research systems to critical infrastructure—I can tell you that Step 3 of the Risk Management Framework (RMF) is where theory meets reality. It's where PowerPoint slides turn into configuration files, policies become procedures, and intentions become measurable security posture.

And it's where most organizations either build a foundation for success or dig themselves into a hole they'll spend years climbing out of.

Understanding What You're Actually Implementing

Let me clear up a common misconception right away: implementing security controls isn't about installing software or buying expensive tools. I've seen organizations spend millions on security products while completely missing the point of NIST 800-53 controls.

Implementation is about creating a systematic approach to protecting your information systems. It's part technology, part process, part people, and entirely about integration.

"Security controls aren't features you add to a system—they're the DNA you build into it from the ground up."

The Three Dimensions of Every Control

Every NIST 800-53 control has three critical dimensions that you must address:

I learned this the hard way in 2016 while working with a Department of Energy contractor. They'd implemented beautiful technical controls—state-of-the-art firewalls, advanced SIEM systems, cutting-edge encryption. But they failed their assessment because they had no documented procedures for using these tools and no management oversight to ensure consistent application.

We had the "what" but not the "how" or the "who monitors."

The Pre-Implementation Reality Check

Before you implement a single control, you need to answer five critical questions. I call this my "Reality Check Framework," and it's saved me from countless implementation disasters.

Question 1: Do You Actually Understand What You Selected?

In Step 2 (Select), you identified which controls apply to your system. But understanding what a control says versus what it means in your environment are two very different things.

Take AC-2 (Account Management). The control statement looks straightforward: manage information system accounts. Simple, right?

Wrong.

For a federal healthcare system I worked with, implementing AC-2 meant:

• Creating accounts for 12,000+ users across 47 different applications

• Establishing approval workflows for 8 different user role types

• Implementing automated provisioning for common roles

• Setting up quarterly access reviews for privileged accounts

• Configuring automatic disablement after 90 days of inactivity

• Integrating with their HR system for employment status changes

One control. Six major implementation workstreams. Dozens of technical and procedural components.

Question 2: Who Owns This Control?

Here's a mistake I see repeatedly: treating security controls as the "security team's job."

Let me share a breakdown of control ownership from a recent Department of Defense project:

Notice how security touches everything but owns relatively few controls outright? That's intentional. Security is a shared responsibility.

"The security team should be the conductor of the orchestra, not the only musician playing."

Question 3: What's Your Implementation Sequence?

You can't implement 421 controls simultaneously. Trust me, I watched an agency try in 2018. It was chaos.

Instead, you need a logical implementation sequence. Here's the approach I've refined over dozens of implementations:

Phase 1: Foundation (Weeks 1-4)

• Identification and Authentication (IA family)

• Basic Access Control (AC-1, AC-2, AC-3)

• System documentation (CM-8, PL-2)

• Security planning documentation (PL-1)

Phase 2: Protection (Weeks 5-10)

• Complete Access Control implementation

• Configuration Management (CM family)

• Media Protection (MP family)

• Physical Protection (PE family)

Phase 3: Detection (Weeks 11-16)

• Audit and Accountability (AU family)

• System and Information Integrity (SI family)

• Security monitoring capabilities

Phase 4: Response (Weeks 17-20)

• Incident Response (IR family)

• Contingency Planning (CP family)

• Maintenance (MA family)

Phase 5: Governance (Weeks 21-24)

• Security Assessment (CA family)

• Planning (PL family completion)

• Risk Assessment (RA family)

• Awareness and Training (AT family)

Question 4: Do You Have the Right Resources?

Let me give you real numbers from a moderate-impact system implementation I led in 2022:

Notice I said "annual cost." Controls aren't implement-once-and-forget. They require ongoing operation and maintenance.

Question 5: What Does "Implemented" Actually Mean?

This is critical. For each control, you need to define your implementation completion criteria. Here's an example for AC-2 (Account Management):

I learned the importance of clear completion criteria the hard way. In 2017, a team told me they'd "finished" implementing AC-2. When I asked for evidence, they showed me the software license. The software was installed but not configured. No procedures existed. Nobody was trained. Nothing was documented.

They'd purchased a control, not implemented one.

The Implementation Approach That Actually Works

After years of trial and error, here's my proven approach for implementing NIST 800-53 controls:

Step 1: Break Down Each Control Into Discrete Tasks

Let me show you how I break down AU-2 (Audit Events) for a typical federal system:

AU-2: Audit Events The organization determines that the information system is capable of auditing specific events and coordinates the security audit function with other organizational entities requiring audit-related information.

Sounds simple. Here's what it actually involves:

That's 430 hours—nearly 11 weeks of full-time work—for a single control. And AU-2 is considered a relatively straightforward control.

"People see one control and think one task. Experienced implementers see one control and count dozens of interdependent activities."

Step 2: Create Implementation Documentation Before You Start

This seems backward, but hear me out. Before implementing a control, I write the System Security Plan (SSP) section describing how it will be implemented.

Why? Because writing forces you to think through the details. It exposes gaps in your understanding. It helps you identify dependencies and resource requirements.

Here's a template I use for every control implementation:

Control: [Control Number and Name]

I had a team member complain that this was "documentation overhead." Two weeks into implementation, he thanked me. The documentation had identified a circular dependency between three controls that would have blocked progress if we'd discovered it during implementation rather than planning.

Step 3: Implement in Layers, Not Silos

Here's a mistake I see constantly: implementing each control completely before moving to the next one. It seems logical, but it's inefficient and creates gaps.

Instead, implement in layers across multiple controls:

Layer 1: Basic Technical Foundation

• Get the technology in place for multiple controls

• Example: Deploy your SIEM (supports AU family, SI-4, IR family)

Layer 2: Configuration

• Configure technical components for specific control requirements

• Example: Configure SIEM to collect specific audit events (AU-2, AU-3, AU-12)

Layer 3: Integration

• Connect components into cohesive workflows

• Example: Integrate SIEM with incident response ticketing (IR-4, IR-5)

Layer 4: Procedures

• Document how people interact with technical controls

• Example: Create procedures for reviewing SIEM alerts

Layer 5: Training

• Ensure people know how to execute procedures

• Example: Train SOC analysts on alert triage

Layer 6: Validation

• Test that everything works together

• Example: Conduct tabletop exercise using SIEM data

I implemented this approach with a federal research agency in 2021. Instead of taking 18 months to implement controls sequentially, we completed implementation in 11 months with better integration and fewer gaps.

Common Implementation Patterns and Pitfalls

Let me share some hard-won lessons:

Pattern 1: Leverage Common Controls

The federal government has invested heavily in common controls—security controls inherited from agency-level programs. These are your friends.

For a recent Department of Commerce project, we identified that 89 of 325 applicable controls were common controls. That meant we only needed to implement 236 system-specific controls—a 27% reduction in implementation scope.

But here's the catch: you must verify that common controls are actually implemented and operating effectively. I've seen agencies claim common controls that didn't actually exist or weren't being maintained.

Pattern 2: Automation Is Your Multiplication Factor

Let me show you the difference automation makes:

That's 3,218 hours—about 1.5 FTE positions—freed up for higher-value security work.

I implemented automation for a Department of Defense system in 2020. The upfront investment was $240,000 for tools and integration. Annual operational savings exceeded $420,000 in reduced labor costs, plus the system became more secure because automated controls are more consistent than manual processes.

"Manual controls fail because people are human. Automated controls fail because people didn't configure them correctly. Choose your risk wisely."

Pitfall 1: The "We'll Document It Later" Trap

I cannot stress this enough: documentation is not a separate phase that comes after implementation.

Here's what happens when you defer documentation:

1. People forget implementation details

2. Evidence gets lost or becomes difficult to locate

3. Knowledge walks out the door when team members leave

4. Auditors can't verify what you've done

5. You end up re-implementing controls to figure out what you did

I worked with an agency in 2019 that had implemented controls for two years without documentation. When their Authorization Official asked for the System Security Plan, they had to spend six months reverse-engineering their implementation and recreating lost evidence.

The project that should have taken 18 months took 30 months because they had to do everything twice.

Pitfall 2: Treating Implementation as a Sprint, Not a Marathon

Control implementation isn't a project with an end date. It's an operational capability that requires ongoing maintenance.

Let me share maintenance requirements for common control families:

That's 1.25 FTE positions just to maintain implemented controls. This isn't overhead—it's operational reality.

Pitfall 3: Implementing to the Letter, Not the Spirit

NIST 800-53 controls describe what to do, but you need to understand why.

I'll give you an example. AC-11 (Session Lock) requires locking user sessions after a period of inactivity. The control's purpose is preventing unauthorized access to unattended sessions.

Implementation to the letter:

• Configure 15-minute timeout

• Document in SSP

• Done

Implementation to the spirit:

• Configure 15-minute timeout for standard workstations

• Configure 5-minute timeout for privileged sessions

• Configure 2-minute timeout for systems processing classified data

• Implement proximity-based locking for mobile devices

• Train users on why session locks matter

• Monitor for users disabling session locks

• Include session lock violations in security awareness metrics

See the difference? One checks a box. The other actually improves security.

Real-World Implementation Example: Building a Complete Control

Let me walk you through how I implemented SC-7 (Boundary Protection) for a federal healthcare system. This will show you how theory becomes practice.

SC-7: Boundary Protection The information system monitors and controls communications at the external boundary and at key internal boundaries.

Phase 1: Understanding Requirements (Week 1)

First, I broke down what SC-7 actually requires:

Phase 2: Design (Weeks 2-3)

We created a network architecture with five security zones:

1. Public Internet (untrusted)

2. DMZ (semi-trusted, public services)

3. Internal Network (trusted, general users)

4. Server Network (trusted, internal servers)

5. Database Network (highly trusted, data storage)

Each boundary between zones had:

• Stateful firewall with default-deny rules

• Intrusion detection sensors

• Network flow monitoring

• Detailed logging sent to SIEM

Phase 3: Implementation (Weeks 4-10)

Week 4-5: Hardware Deployment

• Installed firewall appliances

• Configured network segmentation

• Deployed IDS sensors

Week 6-7: Rule Development

• Documented approved communications

• Created firewall rules for each boundary

• Implemented default-deny policies

• Tested connectivity

Week 8-9: Monitoring Setup

• Configured IDS signatures

• Integrated with SIEM

• Created monitoring dashboards

• Set up alert workflows

Week 10: Documentation & Training

• Updated network diagrams

• Documented firewall rules with business justifications

• Created boundary protection procedures

• Trained network team on new architecture

Phase 4: Validation (Weeks 11-12)

We validated implementation through:

• Penetration testing of boundary controls

• Review of firewall rules by independent team

• Testing of IDS detection capabilities

• Verification of logging and monitoring

• Tabletop exercise simulating boundary attack

Phase 5: Evidence Collection (Week 13)

For the System Security Plan and eventual assessment, we collected:

• Network architecture diagrams

• Firewall configuration files

• IDS configuration and signature versions

• SIEM integration documentation

• Monitoring dashboard screenshots

• Procedure documents

• Training records

• Penetration test results

Total Implementation Effort: 13 weeks, approximately 1,200 hours across multiple team members

Annual Maintenance: Approximately 400 hours for rule reviews, updates, and monitoring

The Implementation Checklist I Use for Every Control

Here's the checklist I run through for each control implementation. It's saved me countless times:

Technical Implementation

• [ ] Required technology identified and procured

• [ ] Technology configured per control requirements

• [ ] Configuration documented and backed up

• [ ] Integration with other systems complete

• [ ] Technical testing completed successfully

• [ ] Technical evidence collected

Procedural Implementation

• [ ] Procedures documented in detail

• [ ] Procedures reviewed and approved

• [ ] Procedures accessible to relevant personnel

• [ ] Procedure ownership assigned

• [ ] Procedure review schedule established

• [ ] Procedural evidence collected

Operational Implementation

• [ ] Responsible parties identified and assigned

• [ ] Training completed for all involved personnel

• [ ] Procedures being followed in daily operations

• [ ] Monitoring in place to verify ongoing compliance

• [ ] Exception handling process defined

• [ ] Operational evidence being collected routinely

Documentation Implementation

• [ ] SSP updated with implementation details

• [ ] Control parameters documented

• [ ] Responsible roles documented

• [ ] Evidence artifacts catalogued

• [ ] Dependencies documented

• [ ] Maintenance requirements documented

Validation

• [ ] Control tested and validated

• [ ] Testing results documented

• [ ] Deficiencies identified and tracked

• [ ] Remediation completed for any issues

• [ ] Independent review completed

• [ ] Assessment evidence package complete

Critical Success Factors I've Learned

After dozens of implementations, these factors separate success from failure:

1. Executive Commitment

I've seen implementations fail because executives viewed security controls as "IT's problem." The most successful implementations had executive sponsors who:

• Allocated adequate resources

• Removed organizational barriers

• Enforced accountability

• Communicated importance throughout organization

2. Cross-Functional Collaboration

Security controls touch every part of an organization. You need buy-in and participation from:

• IT Operations

• Application Development

• Business Units

• HR

• Legal

• Procurement

• Facilities

The Department of Veterans Affairs implementation I worked on succeeded because we had representatives from each group in weekly implementation meetings. When issues arose, we had decision-makers in the room.

3. Realistic Timelines

Here's my rule of thumb for implementation timelines:

These assume adequate resources and experienced personnel. Add 30-50% if you're implementing FISMA controls for the first time.

4. Continuous Documentation

Document as you implement, not after. I use this approach:

• Before implementation: Write SSP description of planned implementation

• During implementation: Update SSP with actual implementation details

• After validation: Finalize SSP with test results and evidence references

This creates accurate documentation and saves enormous time.

5. Evidence Management

Start collecting evidence from day one. I create an evidence repository with folders for each control family and document types:

Evidence Repository/
├── AC - Access Control/
│   ├── Policies/
│   ├── Procedures/
│   ├── Configuration/
│   ├── Reports/
│   └── Testing/
├── AU - Audit and Accountability/
│   ├── Policies/
│   ├── Procedures/
│   └── [etc...]

When assessment time comes, you have organized evidence ready to present.

What Success Looks Like

After proper implementation, you should be able to:

1. Demonstrate control operation - Show assessors that controls are functioning as intended

2. Produce evidence on demand - Quickly locate and present evidence for any control

3. Explain implementation decisions - Justify why you implemented controls the way you did

4. Operate controls efficiently - Maintain controls without excessive manual effort

5. Measure control effectiveness - Track metrics showing controls are working

6. Adapt to changes - Modify controls as system and threats evolve

I'll share one final story. In 2023, I worked with a federal research lab that had struggled with FISMA compliance for five years. They'd been through three failed assessments and two different contractors.

When I arrived, I found controls that were partially implemented, undocumented, and not maintained. We started over with a systematic approach:

• Documented current state honestly

• Prioritized controls based on risk

• Implemented in logical phases

• Built automation wherever possible

• Maintained evidence rigorously

• Trained staff thoroughly

Twelve months later, they achieved their Authority to Operate (ATO). The assessor's comment: "This is the most well-implemented and documented system I've assessed in three years."

The difference? They stopped treating implementation as a checkbox exercise and started treating it as a security engineering discipline.

"Implementation isn't about achieving compliance. It's about building security capabilities that protect your mission while satisfying compliance requirements as a beneficial side effect."

Your Next Steps

If you're facing Step 3 implementation, here's what I recommend:

Week 1: Inventory your selected controls and break them down into discrete implementation tasks

Week 2: Identify control owners and assemble your implementation team

Week 3: Create your implementation plan with realistic timelines and resource requirements

Week 4: Set up your documentation and evidence management systems

Month 2+: Begin phased implementation following the approach outlined in this article

Remember: implementation is where RMF gets real. It's hard work, but it's also where you build actual security capabilities that protect your systems and data.

The federal government processes the most sensitive information in the world through systems protected by these controls. When implemented properly, they work.

Take your time. Do it right. Document everything.

Your future self—and your assessor—will thank you.