The conference room was tense. Across from me sat the IT Director of a mid-sized federal contractor, his compliance officer, and their legal counsel. They'd just received notification that their FISMA assessment had failed—for the second time. The auditor's report was damning: "Organization implemented all 325 baseline controls but failed to demonstrate understanding of why each control was necessary or how it was appropriately applied to their system."
I looked at the 847-page security plan they'd produced. It was a masterpiece of copy-paste compliance. Every control from NIST SP 800-53 was there, verbatim, regardless of whether it applied to their environment or not.
"You know what your biggest problem is?" I said, sliding the document back across the table. "You implemented everything and understood nothing. That's not compliance—that's security theater."
That conversation happened in 2017, but I still see organizations making the same mistake today. They treat FISMA control baselines as unchangeable commandments carved in stone, when in reality, tailoring is not just permitted—it's required for effective security.
What Control Tailoring Actually Means (And Why Most People Get It Wrong)
After fifteen years of helping federal agencies and contractors navigate FISMA compliance, I've learned that control tailoring is the most misunderstood aspect of the Risk Management Framework.
Let me be brutally honest: applying every baseline control without thoughtful tailoring is worse than useless. It wastes resources, creates compliance burden without security benefit, and actually obscures real risks by burying them in irrelevant documentation.
"Control tailoring isn't about cutting corners—it's about applying resources where they actually matter and documenting why you made those decisions."
Here's what many people miss: NIST SP 800-53 explicitly expects organizations to tailor controls. The framework provides baseline controls as a starting point, not a finish line. Your job is to customize those controls to match your specific:
Mission and business functions
System architecture and technology
Threat environment
Risk tolerance
Operational constraints
Budget realities
The Three Pillars of Control Tailoring
Think of tailoring as having three distinct activities, each serving a specific purpose:
1. Scoping: Identifying which controls don't apply to your system at all 2. Parameterization: Defining organization-specific values for control variables 3. Compensating Controls: Substituting alternative controls when baseline controls aren't feasible
I worked with a Department of Defense contractor in 2019 who confused all three. They'd "tailored" their moderate baseline by randomly removing controls they thought were hard (that's not scoping, that's wishful thinking), left all parameters at default values (missing the entire point of parameterization), and never documented a single compensating control despite having several legitimate needs.
Their assessment failed spectacularly. We spent six months fixing what should have been done right the first time.
The FISMA Baseline Reality Check
Before we dive into tailoring, let's ground ourselves in reality. NIST provides three security control baselines based on FIPS 199 impact levels:
Impact Level | Control Families | Approximate Controls | Typical Systems | Tailoring Opportunity |
|---|---|---|---|---|
Low | 17 families | ~125 controls | Public websites, general information systems | Moderate - Some controls may not apply |
Moderate | 17 families | ~325 controls | Most federal systems, contractor systems | High - Significant tailoring needed |
High | 17 families | ~420+ controls | National security systems, critical infrastructure | Lower - Most controls applicable, focus on enhancements |
Here's what nobody tells you: these numbers represent the baseline before tailoring. In my experience, a well-tailored moderate baseline typically reduces to 240-280 actively implemented controls, with clear documentation explaining every tailoring decision.
I remember a federal agency CIO telling me: "We had 325 controls in our plan. After proper tailoring, we actively manage 267. But here's the key—we can now actually explain and defend every single one of those 267. Before tailoring, we couldn't explain most of the 325."
Scoping: The Art of Intelligent Exclusion
Scoping is where organizations either shine or spectacularly fail. Done right, it removes controls that genuinely don't apply to your system. Done wrong, it becomes a wishlist of controls you don't want to implement.
Legitimate Scoping Scenarios
Let me share real examples from systems I've assessed:
Physical Controls for Cloud-Only Systems
I worked with a federal contractor running entirely on AWS GovCloud. Their moderate baseline included extensive physical security controls (PE family). Here's what we scoped out:
Control | Baseline Requirement | Scoping Decision | Justification |
|---|---|---|---|
PE-2 | Physical Access Authorizations | Scoped Out | No physical facilities; AWS responsible per shared responsibility model |
PE-3 | Physical Access Control | Scoped Out | AWS FedRAMP authorization covers facility access |
PE-6 | Monitoring Physical Access | Scoped Out | AWS provides continuous monitoring; contractor has no physical access |
PE-13 | Fire Protection | Scoped Out | AWS data center responsibility per FedRAMP documentation |
PE-14 | Temperature and Humidity Controls | Scoped Out | AWS environmental controls per FedRAMP authorization |
Critical detail: We didn't just delete these controls. We documented:
AWS FedRAMP authorization number and date
Specific AWS responsibility per shared responsibility matrix
How we verify AWS maintains required controls
Annual review process for AWS compliance status
Media Protection for Systems Without Removable Media
A government agency had a web application with no removable media capability. Here's their scoping:
Control | Why It Didn't Apply | What We Did Instead |
|---|---|---|
MP-2 | Media Access | System architecture prohibited removable media; USB ports disabled via Group Policy |
MP-4 | Media Storage | No media to store; documented architectural restriction |
MP-6 | Media Sanitization | Focused on data deletion controls for cloud storage; no physical media disposal needed |
The Scoping Documentation Standard
Here's the template I use with every client. It's saved me countless hours in assessment disputes:
For Each Scoped-Out Control:
Control Identifier and Name: PE-2, Physical Access Authorizations
Baseline Requirement: Control included in NIST 800-53 Moderate Baseline
Scoping Decision: Control scoped out of system security plan
Technical Justification: System operates entirely in AWS GovCloud FedRAMP-authorized environment. No organization-controlled physical facilities house information system components.
Alternative Coverage: AWS maintains PE-2 implementation per FedRAMP authorization AU-XXXXX dated MM/DD/YYYY. Organization validates AWS FedRAMP status quarterly.
Risk Assessment: No additional risk introduced. AWS physical access controls meet or exceed NIST 800-53 requirements.
Approval Authority: [Name], Authorizing Official, [Date]
"Scoping without documentation is just compliance theater. Documented scoping is risk management."
Common Scoping Mistakes (And How to Avoid Them)
I've seen agencies lose their ATO over scoping mistakes. Here are the killers:
Mistake #1: Scoping Out Controls Because They're Difficult
In 2020, I reviewed a system where the organization scoped out AU-6 (Audit Review, Analysis, and Reporting) because they didn't have a SIEM and thought the control was "too hard."
That's not scoping—that's avoidance. AU-6 applies to virtually every system. If you can't implement it as written, you need compensating controls, not scoping.
Mistake #2: Scoping Based on Current Implementation Rather Than System Requirements
A contractor told me they scoped out incident response controls because they "didn't have an incident response team yet." Wrong approach entirely.
Scoping should be based on whether the control applies to your system architecture and functionality, not your current implementation maturity.
Mistake #3: Inadequate Documentation of Scoping Decisions
I've seen security plans that just listed scoped-out controls with a one-word justification: "N/A."
That's not going to fly. Auditors need to understand your reasoning. Authorizing Officials need to accept the risk. Future assessors need to validate your logic.
Parameterization: Defining Your Organization's Values
This is where tailoring gets interesting. Many NIST 800-53 controls include assignment and selection statements—variables you must define based on your organization's needs.
Understanding Assignment and Selection Operations
Let me show you what this looks like in practice:
AC-2: Account Management
The baseline control states:
The organization manages information system accounts, including [Assignment: organization-defined types of accounts] through account establishment, activation, modification, review, and removal processes.
You must define what "organization-defined types of accounts" means for your environment.
Here's how three different organizations I worked with parameterized this:
Organization Type | Account Types Defined | Rationale |
|---|---|---|
Federal Health Agency | Individual user accounts, privileged accounts, system accounts, service accounts, temporary accounts, emergency accounts | Healthcare environment requires granular account management due to HIPAA integration |
DOD Contractor (Development) | Standard user accounts, administrator accounts, service accounts, contractor accounts, temporary accounts | Development environment needs limited account types but strong segregation |
Small Federal Contractor | Employee accounts, contractor accounts, administrator accounts, service accounts | Simplified structure matching organizational size while maintaining required separation |
The key insight: All three organizations implemented AC-2, but their parameterization reflected their actual operational reality.
Critical Parameters That Make or Break Compliance
Based on my experience, here are the parameters that cause the most confusion (and audit findings):
Password Requirements (IA-5)
Parameter | Common Values | Considerations from the Field |
|---|---|---|
Minimum Length | 12-15 characters | I've seen 8-character minimums fail audits. 12+ is the modern standard. |
Complexity Requirements | 3-4 character types | Passphrases are often better than complexity. Document your choice. |
Maximum Lifetime | 60-90 days for privileged, 90-180 for standard | Trend toward longer lifetimes with MFA. Must justify your selection. |
Reuse Prohibition | 10-24 previous passwords | Balance security and usability. Document rationale. |
Real-world example: A federal contractor insisted on 90-day password changes for all users. Their help desk was drowning in reset requests. Users were writing passwords on sticky notes.
We changed to:
180 days for standard accounts WITH mandatory MFA
90 days for privileged accounts
Continuous monitoring for compromised credentials
Password reset tickets dropped 67%. Security improved because users stopped writing passwords down. The auditor accepted our documented rationale.
Session Timeouts (AC-11, AC-12)
I worked with a healthcare contractor whose developers were furious about 15-minute session timeouts. "We can't code like this!" they said.
Here's what we implemented:
Account Type | Inactivity Timeout | System Lock | Justification |
|---|---|---|---|
Standard Users | 30 minutes | 15 minutes | Balances security with operational needs |
Developers (workstations) | 30 minutes | 20 minutes | Development environment requires longer active sessions |
Developers (production) | 15 minutes | 10 minutes | Production access requires heightened security |
Administrators | 15 minutes | 10 minutes | Privileged access demands strict timeout |
Database Admins | 10 minutes | 5 minutes | Direct data access requires maximum protection |
The key: We documented why different roles needed different timeouts. The auditor accepted it because we demonstrated risk-based decision making.
"Good parameterization isn't about choosing the strictest values—it's about choosing the right values for your risk environment and being able to defend those choices."
The Parameterization Documentation I Use
Here's my standard format for documenting parameter decisions:
For Each Parameterized Control:
Control: AC-7, Unsuccessful Logon Attempts
Parameter: [Assignment: organization-defined number] of consecutive invalid logon attempts
Selected Value: 5 unsuccessful attempts
Operational Impact Analysis:
Expected false positive rate: <2% based on 6-month user behavior analysis
Help desk capacity to handle lockouts: 15-20 per day sustainable
Security benefit: Prevents automated password guessing attacks
Alternative Values Considered:
3 attempts: Rejected due to high false positive rate (7% in testing)
10 attempts: Rejected as insufficient protection against brute force
Risk Assessment: 5 attempts provides optimal balance between security and usability. Lower values create excessive operational burden; higher values reduce security effectiveness.
Review Period: Annually, or after significant security events
Approval: [Name], ISSO, [Date]
Compensating Controls: When Standard Controls Don't Fit
This is where tailoring becomes truly strategic. Sometimes you can't implement a baseline control as written—but that doesn't mean you can't achieve the security objective through alternative means.
When Compensating Controls Are Appropriate
I helped a small federal contractor in 2021 who couldn't implement IA-3 (Device Identification and Authentication) as written because their legacy industrial control system literally couldn't authenticate individual devices. This was a $4 million system that would cost over $1 million to replace.
Were they just out of luck? No. We implemented compensating controls:
Original Control | Why Not Feasible | Compensating Control | How It Provides Equivalent Protection |
|---|---|---|---|
IA-3: Device authentication | Legacy ICS cannot authenticate devices | Network segmentation (SC-7) + Enhanced monitoring (SI-4) + Physical access controls (PE-3) | Isolated network segment with no internet connectivity, continuous monitoring of all network traffic, physical access restricted to authorized personnel with multi-factor authentication |
The result: The auditor accepted our compensating controls because we:
Demonstrated technical impossibility of baseline control
Showed equivalent security outcome through combined controls
Documented ongoing monitoring to ensure effectiveness
Committed to implementing baseline control during next system refresh (documented in POA&M)
The Compensating Control Framework
After implementing compensating controls for dozens of systems, here's the framework I use:
Step 1: Demonstrate Why Baseline Control Isn't Feasible
Valid reasons I've successfully defended:
Technical impossibility due to system architecture
Vendor-specific limitations in commercial products
Cost exceeds system value (must provide detailed cost-benefit analysis)
Operational mission impact (with quantified mission degradation)
Invalid reasons that will fail assessment:
"It's too hard"
"We don't have the budget" (without analysis)
"We don't want to"
"It seems unnecessary"
Step 2: Identify Alternative Controls That Meet Security Objective
Key question: What is the control trying to protect against?
Example: AC-17 (Remote Access) requires VPN with FIPS-validated cryptography. But your vendor's VPN appliance isn't FIPS-validated.
Security objective: Protect data in transit during remote access
Compensating approach:
SSH with FIPS 140-2 validated cryptographic module for all administrative access
TLS 1.2+ with FIPS cipher suites for all application access
Network segmentation preventing remote access to sensitive systems without additional authentication
Real-World Compensating Control Success Story
Let me share one of my favorite examples. A research agency had a $15 million scientific instrument that required remote vendor access for calibration. The vendor was based in Europe. The system processed moderate-impact data.
Baseline requirement: AC-17(2) - Use of FIPS-validated cryptography
Problem: Vendor's remote access solution didn't support FIPS-validated crypto and couldn't be changed without voiding warranty.
Our compensating control package:
Security Objective | Compensating Control | Implementation | Validation |
|---|---|---|---|
Protect data confidentiality during transmission | Dedicated encrypted tunnel using agency-managed FIPS-validated VPN endpoint | Site-to-site VPN between agency and vendor facility using FIPS 140-2 Level 2 validated appliance | Quarterly VPN configuration audit |
Ensure only authorized access | Time-limited access windows with advance approval | Vendor must request access 24 hours in advance; access enabled for specific maintenance window only | All access requests logged and reviewed monthly |
Monitor vendor activities | Continuous session recording and analysis | All vendor sessions recorded; automated analysis for suspicious commands; security team notified of anomalies | Weekly review of vendor session recordings |
Prevent unauthorized data exfiltration | Network egress filtering | Vendor access limited to instrument only; all outbound traffic blocked except vendor-specific protocols | Firewall rule validation during each access session |
Outcome: Auditor accepted compensating controls. Agency maintained $15M instrument functionality while meeting security objectives. Vendor was actually happy because the structured access process reduced their liability.
The Tailoring Process: Step-by-Step from Someone Who's Done It 50+ Times
Here's the methodology I've refined over fifteen years and hundreds of systems:
Phase 1: Understanding Your System (Weeks 1-2)
Activities:
Document system architecture in painful detail
Identify all data flows
Map all external connections
Inventory all technology components
Interview all system stakeholders
Deliverable: System Architecture Document that will serve as the foundation for all tailoring decisions
Pro tip from experience: Don't skip this phase. I've seen organizations waste months tailoring controls based on incorrect understanding of their own systems.
Phase 2: Initial Baseline Selection (Week 3)
Based on your FIPS 199 categorization, select your starting baseline.
System Categorization | Baseline | Expected Controls (before tailoring) |
|---|---|---|
Low-Low-Low | Low | ~125 controls |
Any Moderate | Moderate | ~325 controls |
Any High | High | ~420+ controls |
Reality check: If you're a contractor supporting a federal agency, you'll almost certainly need the Moderate baseline minimum. I've never seen a contractor system properly categorized as Low.
Phase 3: Systematic Control Review (Weeks 4-8)
This is where the real work happens. For each control family:
Week 4: Access Control (AC)
Review all 25 AC controls
Identify scoping opportunities
Define all parameters
Document compensating controls if needed
Week 5: Awareness and Training (AT), Audit and Accountability (AU)
Typically fewer scoping opportunities
Focus on parameterization
AT-3 requires defining role-based training content
Week 6: Security Assessment (CA), Configuration Management (CM)
CM family has extensive parameterization needs
CA-2 (Security Assessments) requires defining assessment frequency
Week 7: Contingency Planning (CP), Identification and Authentication (IA)
CP parameters critical: backup frequency, retention periods
IA parameters affect daily operations: password requirements, MFA implementation
Week 8: Incident Response (IR), Maintenance (MA), Media Protection (MP)
IR-4 requires defining incident response timeframes
MP family may have significant scoping for cloud systems
Phase 4: Documentation and Review (Weeks 9-10)
Create comprehensive tailoring documentation:
Required Documentation:
Document | Purpose | Typical Length | Audience |
|---|---|---|---|
Tailoring Summary | Executive overview of all tailoring decisions | 5-10 pages | AO, senior management |
Detailed Scoping Justifications | Technical explanation for each scoped control | 15-30 pages | Assessors, technical reviewers |
Parameter Definition Matrix | All parameterized controls with selected values and rationale | 10-20 pages | System administrators, operators |
Compensating Controls Analysis | Detailed analysis for each compensating control | Varies by number | Assessors, AO |
Review Process I Recommend:
Technical Review (ISSO, System Owner): Validate technical accuracy
Operations Review (System Administrators, Users): Ensure operational feasibility
Security Review (Security Team): Verify security objectives are met
Management Review (AO, Senior Leadership): Accept risk decisions
External Review (Assessor): Pre-assessment validation
"The time you invest in documentation during tailoring will save you exponentially more time during assessment and ongoing authorization."
Common Tailoring Pitfalls (And How I've Learned to Avoid Them)
Pitfall #1: Over-Tailoring
I assessed a system in 2019 where the organization had scoped out 87 controls from the moderate baseline. That's roughly 27% of the baseline.
Red flag immediately went up.
After review, only 12 of those scoping decisions were legitimate. The rest were wishful thinking disguised as tailoring. We had to reimplement 75 controls. The ATO was delayed by four months.
My rule of thumb: If you're scoping out more than 15-20% of baseline controls, you probably need to reconsider your decisions.
Pitfall #2: Under-Documenting Tailoring Decisions
"We scoped out PE controls because cloud."
That's not documentation. That's asking for an audit finding.
Real documentation looks like this:
Control: PE-3, Physical Access Control Scoping Decision: Scoped Out System Architecture: System operates entirely within AWS GovCloud FedRAMP-authorized environment. Organization maintains no physical data center or server room facilities. Shared Responsibility Analysis: AWS implements PE-3 controls at physical facility level per FedRAMP Authorization Package AU-12345, dated January 15, 2023. AWS maintains FIPS 201-compliant PIV access control, biometric verification, and mantrap configurations at all data centers. Verification Process: Organization reviews AWS FedRAMP authorization status quarterly via FedRAMP Marketplace. Any changes to AWS authorization status trigger immediate security plan review. Residual Risk: Minimal. AWS physical controls exceed NIST 800-53 moderate baseline requirements. Organization maintains no independent verification capability of AWS physical controls but relies on FedRAMP JAB authorization process. Approval: Jane Smith, Authorizing Official, March 15, 2024
See the difference?
Pitfall #3: Static Tailoring
I worked with an agency whose tailoring documentation was from 2015. Their system had migrated to cloud, added new integrations, and tripled in user count.
None of this was reflected in their tailored controls.
Best practice: Review tailoring decisions annually minimum, and whenever:
System architecture changes significantly
New integrations are added
User population changes substantially
Threat environment evolves
New technologies are introduced
Tailoring for Different System Types
Not all systems tailor the same way. Here's guidance based on system categories I've worked with:
Cloud-Hosted Systems (The Most Common Scenario Now)
Typical Scoping Opportunities:
Physical security controls (PE family) - Most can be scoped to cloud provider
Environmental controls (PE-14, PE-15) - Cloud provider responsibility
Some media protection controls (MP-2, MP-4) - If no removable media capability
Critical Parameterization:
Backup requirements (CP-9) - Define frequency based on RPO/RTO requirements
Access control (AC family) - Define cloud-specific access controls
Configuration management (CM family) - Include both cloud infrastructure and application layers
Common Mistakes:
Over-scoping PE controls without verifying cloud provider FedRAMP authorization
Forgetting that shared responsibility still requires organization controls for application layer
Inadequate documentation of how organization verifies cloud provider controls
Legacy On-Premises Systems
Typical Scoping Opportunities:
Fewer than cloud systems - Most controls apply
Some newer controls (cloud-specific enhancements) may not be relevant
Critical Parameterization:
Physical access controls - Must define organization-specific requirements
Maintenance windows - Legacy systems often have limited maintenance windows
Backup and recovery - May be constrained by legacy technology
Common Mistakes:
Trying to apply modern controls to systems that can't support them without compensating control documentation
Inadequate justification for parameter values that reflect legacy limitations
Failing to document modernization plans in POA&M
Hybrid Environments (The Trickiest)
Typical Scoping Opportunities:
Limited - Must address both on-premises and cloud components
Critical Parameterization:
Access controls must account for both environments
Backup and recovery strategies may differ by component
Incident response must address both environments
Common Mistakes:
Inconsistent tailoring between on-premises and cloud components
Failing to address control implementation at integration points
Inadequate documentation of data flows between environments
The Business Impact of Good Tailoring
Let me share some numbers from my consulting practice:
Organization A: Federal Contractor (Before Tailoring)
Security plan: 843 pages
Time to implement: 18 months
Annual compliance burden: 2,400 hours
Failed initial assessment: 47 findings
Organization A: Federal Contractor (After Proper Tailoring)
Security plan: 387 pages
Time to implement: 9 months
Annual compliance burden: 980 hours
Passed assessment: 3 minor findings
Cost savings: $340,000 annually in reduced compliance burden
Organization B: Federal Agency (Moderate Baseline)
Metric | Without Tailoring | With Tailoring | Improvement |
|---|---|---|---|
Security Controls Managed | 325 | 267 | 18% reduction |
Controls Team Can Explain | 134 (41%) | 267 (100%) | 59% improvement |
Annual Audit Findings | 23 | 4 | 83% reduction |
Time to Address Findings | 4.2 months average | 0.8 months average | 81% faster |
Compliance Staff Required | 4.5 FTE | 2.8 FTE | 38% reduction |
"Proper tailoring doesn't reduce security—it focuses security resources where they actually matter."
My Final Advice After 15 Years of FISMA Assessments
Start with Understanding, Not Cutting
Don't begin tailoring with the goal of reducing controls. Begin with the goal of understanding which controls genuinely protect your system.
I've seen organizations implement 50 "extra" controls beyond baseline because those controls addressed their specific risks. That's good tailoring.
I've also seen organizations try to justify scoping out core controls because they seemed hard. That's not tailoring, it's hoping auditors won't notice.
Document Everything
The time you spend documenting tailoring decisions will pay dividends during:
Initial assessment
Continuous monitoring
Annual assessments
System changes
Staff transitions
Auditor questions
I promise you: "We talked about this three years ago and decided to scope it out" won't satisfy an auditor.
Engage Your Assessor Early
Here's an insider secret: most assessors are happy to provide pre-assessment guidance on tailoring approaches.
I've worked with dozens of assessors who've said: "If you'd asked me about this scoping decision before the assessment, I could have told you it wouldn't fly. Now we're in findings remediation instead of having a productive conversation."
Treat Tailoring as Living Documentation
Your first tailoring effort won't be perfect. Mine never is.
But if you've documented your reasoning, you can refine it. If you've established a review process, you can improve it. If you've built organizational understanding, you can evolve it.
The organizations that succeed with FISMA aren't the ones who get tailoring perfect on day one. They're the ones who build tailoring into their security practice and continuously improve.
Your Tailoring Action Plan
Based on where you are in your FISMA journey:
If You Haven't Started:
Week 1: Complete thorough system architecture documentation
Week 2: Confirm your baseline selection
Weeks 3-8: Systematic control-by-control review
Weeks 9-10: Documentation and stakeholder review
Week 11-12: Pre-assessment review with your assessor
If You Have Existing Controls (But No Tailoring):
Conduct gap analysis between current implementation and baseline
Identify quick wins (obvious scoping opportunities)
Prioritize parameterization of highest-impact controls
Document what you're already doing before making changes
If You Have Poor Tailoring Documentation:
Start with highest-risk scoping decisions
Add justification for each scoped control
Document all parameterized values with rationale
Create compensating control documentation where needed
The Truth About Tailoring
Here's what I wish someone had told me when I started in FISMA compliance:
Control tailoring is not about gaming the system. It's not about reducing your workload (though that's a benefit). It's not about finding loopholes.
Tailoring is about applying security controls intelligently, documenting your decisions transparently, and accepting responsibility for the risks you choose to address or accept.
Done right, tailoring transforms FISMA compliance from a compliance burden into a risk management process. It changes security from something you do to satisfy auditors into something that actually protects your systems.
I've worked with organizations who've achieved this. Their security plans are clear. Their teams understand what they're doing and why. Their audits are conversations, not interrogations.
That's the power of proper tailoring.
And it's absolutely worth the effort.