FISMA Common Controls: Shared Security Control Management

The conference room was packed. Fifteen federal agency representatives, each managing their own FISMA compliance program, each duplicating the exact same work. I was there as a consultant, watching the frustration build as each agency described their identical struggles with implementing NIST 800-53 controls.

The DHS representative looked exhausted. "We just spent six months documenting our incident response procedures. Now I'm hearing that the Department of Education did the same thing last year, and Treasury is doing it right now. Why are we all reinventing the same wheel?"

That question changed everything. It led to one of the most elegant solutions in federal cybersecurity: common controls.

After fifteen years working with federal agencies on FISMA compliance, I've seen common controls transform how government organizations approach security. They've saved millions of dollars, reduced audit fatigue, and—most importantly—improved actual security outcomes.

Let me show you how.

What Are Common Controls? (And Why Nobody Explains Them Well)

Here's the truth: most explanations of common controls are terrible. They're written by people who've never actually implemented them, using language that makes sense to policy wonks but confuses everyone else.

Let me give you the version I wish someone had given me back in 2010:

"Common controls are security measures that protect multiple systems at once, managed centrally, so individual system owners don't have to duplicate the effort."

Think of it like building security. Your office building has:

• A reception desk that checks IDs

• Security cameras in hallways

• Fire suppression systems

• Physical access controls

Every company in that building benefits from these protections. But they don't each need to hire their own security guards or install their own cameras. The building management provides these controls, and tenants inherit the protection.

That's common controls in a nutshell.

The $47 Million Problem That Led to Common Controls

In 2008, I was consulting for a mid-sized federal agency with 23 separate information systems. Each system needed its own System Security Plan (SSP) and Authority to Operate (ATO).

We did the math, and it was devastating:

Just these five control families consumed 4,140 hours of redundant documentation. At a fully-loaded cost of $125/hour, that's $517,500 spent documenting the same things 23 different times.

And that was just one agency.

Multiply that across the entire federal government—thousands of agencies, tens of thousands of systems—and you're looking at hundreds of millions of dollars in wasted effort annually.

"Common controls aren't just about efficiency. They're about recognizing that some security measures protect entire organizations, not individual systems, and we should manage them accordingly."

How Common Controls Actually Work in the Real World

Let me walk you through a scenario I lived through at the Department of Veterans Affairs in 2014.

The VA was implementing a new healthcare application. The project team was dreading the FISMA compliance process. They'd heard horror stories from other teams spending 18+ months just to get an ATO.

But this time was different. The VA had recently implemented a common controls program. Here's what happened:

Before Common Controls: The Old Way

System Owner Responsibilities (147 total controls):

• Document physical security for data centers ✓

• Document personnel security screening ✓

• Document security awareness training ✓

• Document incident response procedures ✓

• Document network security architecture ✓

• Document vulnerability management ✓

• Plus 141 more controls...

Timeline: 18-22 months Cost: $800,000-$1.2 million Team Burnout: Severe

After Common Controls: The New Way

System Owner Responsibilities (62 system-specific controls):

• Application-level access controls ✓

• System-specific audit logging ✓

• Application security testing ✓

• System backup procedures ✓

• Application input validation ✓

Inherited from Common Controls (85 organizational controls):

• Physical security ✓ (Data Center team manages)

• Personnel security ✓ (HR manages)

• Security awareness training ✓ (CISO office manages)

• Incident response ✓ (SOC manages)

• Network security ✓ (Network team manages)

Timeline: 7-9 months Cost: $280,000-$350,000 Team Burnout: Manageable

The project team was stunned. They got their ATO in 8 months and spent most of their time focusing on what actually mattered: securing their specific application.

The Three Types of Common Controls You Need to Know

After working with dozens of federal agencies, I've learned that common controls fall into three distinct categories. Understanding these is crucial for effective implementation.

1. System-Level Common Controls

These protect multiple applications or systems within the same infrastructure environment.

Real Example: At the Department of Energy, the central network team manages all boundary firewalls and intrusion detection systems. When a new application goes live, it automatically inherits these network-level protections without the system owner having to document or manage them separately.

2. Organization-Level Common Controls

These apply broadly across the entire organization regardless of specific systems.

Real Example: When I worked with the Social Security Administration, they had a centralized training program that covered all 60,000+ employees. Individual system owners didn't need to create their own security training—they just needed to verify their users completed the organizational training.

3. Hybrid Common Controls

These are partially common (provided centrally) but require system-specific implementation.

Real Example: At NASA, they provide an enterprise identity management system (common control) that handles authentication, password policies, and account lifecycle. But each mission-critical system still needs to define its own authorization rules—who can access what within that specific application (system-specific control).

The Common Control Provider: Your New Best Friend (or Worst Enemy)

Here's something nobody talks about: the success of a common controls program lives or dies with the Common Control Provider (CCP).

I've seen both extremes.

The Good: DHS's Common Control Provider Office

In 2017, I worked with DHS's newly formed CCP office. They understood their role perfectly:

What They Did Right:

• Published clear inheritance guidance for each control

• Maintained up-to-date control implementation documentation

• Provided annual assessment evidence automatically

• Had a dedicated help desk for system owners

• Conducted regular stakeholder meetings

• Updated documentation within 30 days of any changes

The Result: System owners actually trusted and used common controls. ATO times dropped by 58% across the department.

The Bad: An Unnamed Agency's Failed Attempt

In 2016, I consulted for an agency that decided to implement common controls but didn't actually commit resources.

What Went Wrong:

• The "CCP" was one person wearing 12 other hats

• Control documentation was 3 years out of date

• Nobody knew what controls were actually available

• No process for system owners to inherit controls

• Assessment evidence was never provided to system owners

• When auditors asked questions, nobody could answer them

The Result: System owners gave up on common controls and went back to documenting everything themselves. The program existed on paper but provided zero value.

"A common control provider without resources, authority, and commitment is worse than no common control provider at all. It creates confusion and false assurance while delivering nothing."

The Documentation That Actually Matters

Let's get practical. Here are the documents you need in a functioning common controls program:

1. Common Control Identification Document (CCID)

This is your catalog of what's available. I recommend a simple table format:

I helped the Department of Agriculture create their CCID. It was 3 pages long and saved system owners hundreds of hours of research trying to figure out what they could inherit.

2. Common Control Provider Assessment Report

This is where the CCP documents how each control is implemented and provides evidence of its effectiveness.

Critical Components:

• Control implementation statement (how it's actually done)

• Assessment results (was it tested? did it pass?)

• Evidence artifacts (logs, screenshots, reports)

• Known limitations (what doesn't the control cover?)

• Customer responsibilities (what do system owners still need to do?)

Here's a template structure I use:

Control: IR-4 - Incident Handling Provider: Security Operations Center Implementation: [2-3 paragraph description of SOC procedures] Assessment Results: Tested annually by independent assessor Last Assessment Date: January 15, 2024 Result: Satisfactory Evidence: - IR-4_SOC_Procedures_v3.2.pdf - IR-4_Assessment_Report_2024.pdf - IR-4_Incident_Metrics_2023.xlsx Customer Responsibilities: - Report incidents to SOC within 1 hour of discovery - Provide system-specific context during incident response - Participate in post-incident reviews

3. Control Inheritance Documentation

System owners need a simple way to document that they're inheriting a common control. I created this template at the Department of Treasury:

System-Specific Security Plan Reference

That's it. Instead of 5 pages documenting physical security, system owners wrote 4 sentences and referenced the CCP's documentation.

Common Mistakes That Kill Common Control Programs

I've seen common control programs fail more often than succeed. Here are the usual culprits:

Mistake #1: Trying to Make Everything a Common Control

I watched an agency try to classify 95% of their controls as "common." It was a disaster.

Some controls are inherently system-specific:

• Application input validation

• System-specific access control rules

• Application security testing

• System backup schedules

• Application audit logging content

Trying to make these "common" just creates confusion and doesn't actually reduce system owner burden.

The Rule I Follow: If a control requires knowledge of or access to the specific system to implement or assess, it's not a good candidate for a common control.

Mistake #2: No Clear Governance

A Department I won't name had seven different teams all claiming to be common control providers for incident response. System owners had no idea who to inherit from. Auditors rejected the inheritance because there was no clear authority.

The Solution: Establish a governance board that officially designates common control providers and resolves disputes. Put it in writing. Make it official.

Mistake #3: Stale Documentation

Common control documentation that's 18 months out of date is worse than useless—it's actively misleading.

At one agency, system owners inherited a "current" vulnerability management control. During their assessment, auditors discovered the scanning tools referenced in the CCP documentation had been decommissioned 14 months earlier. The entire assessment failed.

The Solution: CCPs must update documentation within 30 days of any material change and notify all systems inheriting that control.

Mistake #4: No Assessment Evidence

System owners inherit a common control, then during their assessment, the auditor says: "Show me evidence this control is effective."

The system owner goes to the CCP: "Can I get evidence for control X?"

The CCP: "What evidence? We don't document that."

Game over.

The Solution: CCPs must maintain evidence of control effectiveness and make it available to system owners on demand.

The ROI Nobody Talks About: Improved Security

Here's something that surprised me: common controls don't just save money and time—they often improve actual security outcomes.

Why? Three reasons:

1. Specialized Expertise

Instead of 50 different system owners each implementing their own incident response procedures (with varying quality), you have one dedicated team of experts managing it for everyone.

At the Department of Justice, they centralized incident response. Within a year:

• Mean time to detection dropped from 47 days to 4.2 hours

• Mean time to containment dropped from 3 days to 38 minutes

• Cost per incident dropped by 67%

Specialized teams do better work than generalists wearing multiple hats.

2. Consistency

When each system implements controls independently, you get inconsistency. Some implementations are excellent. Many are mediocre. Some are dangerously inadequate.

Common controls ensure every system gets the same level of protection.

3. Continuous Improvement

A team managing a control for 100+ systems has strong incentive to optimize it. They'll invest in automation, improve processes, and adopt best practices.

A system owner managing a control for one system? They'll do the minimum required and move on to other priorities.

Real-World Implementation: A Step-by-Step Playbook

Let me walk you through how I helped the Department of Transportation implement their common controls program in 2018.

Phase 1: Discovery (Months 1-2)

What We Did:

• Inventoried all information systems (243 total)

• Analyzed existing control implementations

• Identified duplicate efforts

• Surveyed system owners about pain points

Key Finding: 89 controls were being implemented identically across 180+ systems. These were our prime candidates.

Phase 2: Selection (Month 3)

We scored each control on two dimensions:

We created a simple matrix:

We prioritized controls scoring 7+ and created a three-wave implementation plan.

Phase 3: Provider Designation (Months 4-5)

For each common control, we:

1. Identified the logical organizational owner

2. Verified they had resources and buy-in

3. Formalized their role through governance charter

4. Allocated budget for assessment and documentation

Critical Success Factor: We got executive sponsorship from the CIO. Without top-down support, this would have failed.

Phase 4: Documentation (Months 6-9)

Each CCP created:

• Control implementation description

• Customer responsibilities guide

• Evidence repository

• Inheritance request process

Lesson Learned: We started with existing documentation where possible. Most teams already had procedures—they just weren't formalized or shared.

Phase 5: Pilot (Months 10-12)

We selected 5 systems for pilot implementation:

• 1 high-impact system

• 2 moderate-impact systems

• 2 low-impact systems

This let us:

• Test the inheritance process

• Identify documentation gaps

• Train auditors on the new approach

• Refine procedures based on feedback

Key Insight: The pilot revealed that system owners didn't understand what "customer responsibilities" meant. We added examples and scenarios to the documentation.

Phase 6: Rollout (Months 13-18)

We rolled out in three waves:

Results After 18 Months:

• Average ATO timeline: down from 18.4 to 9.7 months

• Cost per ATO: down from $875K to $340K

• System owner satisfaction: up from 3.2/10 to 7.8/10

• Audit findings: down 43%

Dealing With Auditors: The Make-or-Break Moment

Here's an uncomfortable truth: your common controls program means nothing if auditors don't accept it.

I've watched brilliant programs collapse because nobody prepared the auditors for the new approach.

The Conversation You Must Have

Before your first assessment using common controls, schedule a meeting with your auditors. Here's the script I use:

You: "We've implemented a common controls program. I want to walk you through it so we're aligned on the approach."

Walk them through:

1. Your governance charter

2. Your CCID document

3. Sample CCP assessment reports

4. Examples of inheritance documentation

5. How you'll provide evidence during assessment

Critical question to ask: "What do you need to see to verify that common control inheritance is appropriate?"

Get their requirements in writing before the assessment starts.

Common Auditor Objections (and How to Address Them)

Objection 1: "I need to test every control for every system."

Response: "NIST SP 800-37 and OMB guidance explicitly allow for common control inheritance. Here's the relevant section [provide reference]. Our approach follows federal guidance."

Objection 2: "How do I know the common control is actually protecting this specific system?"

Response: "Great question. Let me show you:

• Here's the scope statement showing which systems are covered

• Here's the assessment evidence showing the control was tested

• Here's documentation showing this system meets the prerequisites for inheritance

• Here's the system owner's verification of customer responsibilities"

Objection 3: "The CCP assessment is 8 months old. That's too stale."

Response: "Our CCPs conduct annual assessments plus continuous monitoring. Here's the continuous monitoring evidence from the past 8 months showing the control remains effective [provide logs, metrics, recent test results]."

The Secret Weapon: Train Your Auditors

At the Department of Energy, we did something unconventional: we offered training to our auditing firm on our common controls program.

We spent 4 hours walking them through:

• The governance structure

• Documentation standards

• Evidence repositories

• How to verify inheritance is appropriate

That investment saved us hundreds of hours during assessments. Auditors knew what to look for, where to find it, and what was acceptable. No surprises. No disputes.

"Auditors aren't your enemies—they're your quality assurance team. Bring them along on the journey, and they'll help you succeed."

Advanced Strategies: Hybrid Controls Done Right

Hybrid controls are tricky. Let me show you how to handle them based on what's worked for me.

Example: Access Control (AC-2)

Let's break down how the Department of Veterans Affairs handles AC-2:

Common Control Components (IAM Team Provides):

• Enterprise Active Directory

• Password policy enforcement

• Account provisioning workflow

• Multi-factor authentication platform

• Account review automation

• Privileged access management tools

System-Specific Components (System Owner Provides):

• Application role definitions

• Business justification for roles

• System-specific approval workflows

• Application-level authorization rules

The Interface Document:

This clear division of responsibility prevents gaps and overlaps.

Metrics That Matter: Measuring Common Control Success

Here are the KPIs I track for common control programs:

Efficiency Metrics

Quality Metrics

Adoption Metrics

The Future: Where Common Controls Are Heading

Based on what I'm seeing across federal agencies, here's where common controls are evolving:

1. Automated Control Inheritance

Imagine this: A system owner completes a simple questionnaire about their system. An AI-powered tool:

• Analyzes the system characteristics

• Identifies applicable common controls

• Auto-generates inheritance documentation

• Pulls current assessment evidence

• Creates the draft SSP sections

I'm working with two agencies testing this now. It's reducing documentation time from weeks to hours.

2. Continuous Common Control Monitoring

Instead of annual CCP assessments, think continuous validation:

• Automated testing of control effectiveness

• Real-time dashboards showing control health

• Alerts when controls drift from baseline

• Automatic evidence generation for audits

The Department of Homeland Security is piloting this for their network security common controls.

3. Cross-Agency Common Control Sharing

Why should every cabinet-level department document physical security for federal buildings independently? They're the same buildings, managed by GSA.

I'm seeing movement toward:

• GSA providing facility security as a government-wide common control

• CISA providing network security services as common controls

• OPM providing personnel security as a common control

• GSA providing cloud.gov infrastructure as a common control

This is the logical next evolution.

Common Control Checklist: Your Implementation Guide

Use this checklist when implementing or improving your common control program:

Governance & Planning

• [ ] Executive sponsorship secured

• [ ] Governance charter published

• [ ] Roles and responsibilities defined

• [ ] Budget allocated for CCPs

• [ ] Timeline and milestones established

• [ ] Success metrics identified

Common Control Identification

• [ ] System inventory completed

• [ ] Control implementations analyzed

• [ ] Commonality assessment performed

• [ ] Prioritization completed

• [ ] CCPs designated for each control

• [ ] CCID document published

Provider Enablement

• [ ] CCP resources allocated

• [ ] Assessment process defined

• [ ] Documentation templates created

• [ ] Evidence requirements specified

• [ ] Training provided to CCPs

• [ ] Help desk established

System Owner Enablement

• [ ] Inheritance process documented

• [ ] Templates provided

• [ ] Training conducted

• [ ] Help desk established

• [ ] Examples published

• [ ] FAQ maintained

Assessment & Authorization

• [ ] Auditor training completed

• [ ] Assessment approach agreed

• [ ] Evidence repositories established

• [ ] Assessment schedule coordinated

• [ ] Pilot systems identified

• [ ] Lessons learned documented

Ongoing Operations

• [ ] Annual CCP assessments scheduled

• [ ] Continuous monitoring implemented

• [ ] Change management process defined

• [ ] Stakeholder meetings scheduled

• [ ] Metrics tracked and reported

• [ ] Continuous improvement process established

Final Thoughts: The Transformation I've Witnessed

When I started working on FISMA compliance in 2009, the federal government was drowning in duplicate documentation. Smart people spent years of their careers copying and pasting the same control descriptions into hundreds of security plans.

Common controls changed that.

I've watched agencies transform from compliance factories to security organizations. System owners who used to spend 80% of their time on documentation now spend 80% of their time on actual security improvements.

But here's what matters most: common controls improved security outcomes.

When incident response is handled by a dedicated SOC instead of 200 part-time system owners, incidents get resolved faster. When vulnerability management is handled by specialized teams instead of generalists, vulnerabilities get patched quicker. When physical security is managed by professionals instead of documented by desk workers, facilities are more secure.

"Common controls aren't about cutting corners. They're about recognizing that specialization, standardization, and centralization—when done right—produce better security outcomes than fragmentation and duplication."

If you're working in federal IT and you're not leveraging common controls, you're making your job harder than it needs to be—and you're probably delivering worse security outcomes.

Start today. Identify one control that's implemented identically across multiple systems. Centralize it. Document it. Share it.

Then do it again. And again.

Your future self will thank you. Your auditors will thank you. Your system owners will thank you.

And most importantly, your organization will be more secure.