If you are asking what FISMA compliance will demand of your team, the honest answer is that the cost and the calendar are driven by three things, and none of them is the control count. The first is your categorization: a system rated high for confidentiality, integrity or availability inherits a far larger control baseline and a far more skeptical reviewer than a low system. The second is how much you inherit from a provider or a common control program versus how much you must implement and evidence yourself. The third is the condition of your engineering practice before assessment begins, because every control that is real in production but undocumented becomes rework, and every control that is documented but not real becomes a finding. Teams that manage those three variables well spend their effort on engineering. Teams that do not spend it rewriting a System Security Plan under deadline.
The sequence matters as much as the substance. The NIST Risk Management Framework runs prepare, categorize, select, implement, assess, authorize and monitor, and it is ordered that way for a reason. Categorization sets the baseline, the baseline drives selection and tailoring, tailoring determines what implementation actually means for your architecture, and only then does assessment have a fixed target. Work that jumps straight to control narratives before the system boundary is settled gets redone. Our advice to every program we support is to spend disproportionate time on preparation and boundary definition, because those decisions are cheap to change on a whiteboard and expensive to change in a package that is already in front of an authorizing official.
Preparation and the system boundary
Prepare is the step most teams skip and most reviewers notice. Before any control is selected, someone has to name the system, draw its boundary, identify the information types it processes, list the interconnections, assign the roles, and establish the organizational risk tolerance that the authorizing official will judge against. A boundary drawn too wide swallows infrastructure you do not control and forces you to evidence things that belong to someone else. A boundary drawn too narrow leaves dependencies dangling outside the authorization, and the first reviewer question will be who authorized those.
The practical test is whether you can describe, in one diagram and one page of text, where data enters, where it rests, where it leaves, who administers each component, and what crosses the boundary in each direction. If that description requires caveats, the boundary is not settled yet. Getting it right also determines your inheritance story: what you receive from an authorized cloud provider, what comes from an enterprise common control provider, and what is genuinely yours. Inheritance is the single largest lever on effort, and it has to be claimed precisely, with the provider's authorization package and customer responsibility matrix actually read rather than assumed.
Categorization: the decision everything else hangs on
Categorization under FIPS 199 and NIST SP 800-60 asks you to identify the information types the system handles and assign a potential impact of low, moderate or high to confidentiality, integrity and availability. The system category is the high water mark across those. This is a business decision documented by engineers, not an engineering decision, and it should involve the system owner and the mission stakeholders. Two failure modes recur. Overcategorization is the more common one: a team rates everything high to seem careful and then spends the rest of the program justifying controls their mission does not need. Undercategorization is rarer but more damaging, because it surfaces during assessment or, worse, during an incident, and it invalidates the selection work built on top of it.
Write down the reasoning, not just the rating. The authorizing official is being asked to accept risk, and a categorization with a documented rationale for each information type is the first evidence that the risk was actually considered. A rating with no rationale reads as a guess, and reviewers treat it that way.
Control selection and tailoring
Selection starts from the NIST SP 800-53 baseline in SP 800-53B that corresponds to your category, then tailors it. Tailoring is a formal activity and it is where competent programs separate from cargo-cult ones. You can scope out controls that do not apply to your architecture, apply compensating controls where the stated control is technically infeasible, assign values to organization-defined parameters, and layer on overlays your agency or program requires. Every one of those moves needs a written justification that an assessor can evaluate.
- Scoping: a control that addresses a technology you do not use can be marked not applicable, but only if the boundary genuinely excludes it. Mobile code controls on a system with no mobile code is a fair scope-out; physical controls on a system you say is cloud-hosted are usually an inheritance claim, not a scope-out.
- Compensating controls: state the control you cannot meet, the reason, the alternative you implemented, and why the alternative provides equivalent protection. The third and fourth parts are the ones that get skipped and the ones reviewers read first.
- Parameters: organization-defined values for things like session timeout, audit retention and password policy must match what the system actually enforces. A mismatch between the documented parameter and the configuration is a finding that takes ten minutes to discover and weeks to remediate across a fleet.
- Overlays: privacy, classified, or program-specific overlays change the baseline. Identify them before you write narratives, not after.
Tailoring done early and deliberately shrinks the package. Tailoring done late, as an attempt to explain away findings, reads defensively and rarely survives review.
Implementation and the documentation trap
Implementation is where the control becomes real in the environment. The trap is treating documentation as a parallel activity that catches up later. It never catches up. The System Security Plan should describe the system as built, and the closer the SSP sits to the engineering workflow, the more likely it stays accurate. Programs that generate configuration evidence from infrastructure as code, that tie control statements to specific pipeline stages and specific enforcement points, and that treat a drift in configuration as a defect rather than a paperwork problem, walk into assessment with far less to explain.
This is also where automation earns its place. Inventory, vulnerability scanning, configuration baselines, log aggregation, access recertification and evidence collection are all repeatable, and anything repeatable that a human does by hand before an assessment will be done inconsistently. We build this plumbing as part of our security and compliance assessment work, because a package assembled from live system state is both faster to produce and harder to dispute. Our own engineering and platform practices are described on our security page.
Assessment: what a good SAR looks like
Assessment tests whether the controls are implemented correctly, operating as intended and producing the desired outcome. The assessor works from a Security Assessment Plan built on SP 800-53A, exercises each control through examination, interview and testing, and produces a Security Assessment Report. Where an independent assessment body is required, we deliver that work with accredited partners and keep our own role on the engineering and remediation side, which avoids the conflict of an implementer grading their own work.
Prepare your team for the interview portion specifically. Assessors ask the person who runs the process, not the person who wrote the narrative, and a confident answer that contradicts the SSP is worse than an uncertain one that matches it. Before assessment, have someone outside the build team try to reproduce each control claim from the evidence alone. Anything they cannot verify, an assessor will not verify either.
Authorization and what the AO is actually looking for
The authorizing official is a government official accepting risk on behalf of the mission, personally and in writing. They are not auditing your control count. They are asking a short list of questions: do I understand what this system does and what it touches, do I believe the categorization, do I trust the assessment that produced these findings, are the open weaknesses tracked with realistic remediation, and is there a credible plan to tell me when the risk changes.
The artifacts that answer those questions are the ones that make or break a package. The SSP has to match reality. The SAR has to be independent and specific. The Plan of Action and Milestones has to be honest: a POA&M with plausible dates, named owners and real resourcing signals a program in control, while one full of open items with no owner signals the opposite, and a suspiciously empty POA&M signals an assessment that did not look hard. Supporting artifacts — contingency plan, incident response plan, configuration management plan, privacy documentation, interconnection agreements — should be tested rather than merely written. An AO who finds that the contingency plan has never been exercised will discount everything else in the package. We keep a broader set of practitioner guides on this topic, and the questions in our guide on what to ask an automation vendor apply equally to anyone you plan to inherit controls from.
Continuous monitoring is the actual steady state
Authorization is a point-in-time decision about a system that changes daily. Continuous monitoring, under SP 800-137, is what keeps the decision valid. It covers vulnerability and configuration monitoring, control effectiveness reassessment on a defined frequency, significant change analysis, and regular reporting to the authorizing official. Ongoing authorization depends on it: if your monitoring is real and reported, reauthorization becomes a review of deltas rather than a rebuild.
Define in advance what constitutes a significant change requiring reassessment, and put that definition where engineers will see it. New data type, new external interconnection, a change in cryptographic posture or authentication model, a material architecture shift — these need a security impact analysis before deployment, not a note in the next quarterly report. The best programs we work with treat monitoring output as an engineering input: failed configuration checks land in the same queue as production defects, and the POA&M is groomed like a backlog rather than resurrected before an annual review.
Where the effort actually goes
Across the programs we support, the cost drivers repeat. Boundary and inheritance decisions made late. Categorization without documented rationale. Narratives written from intent instead of from configuration. Evidence collected by hand. Contingency and incident plans that exist but have never been run. A POA&M maintained as a compliance artifact rather than as work. Every one of those is fixable before assessment and expensive after it.
If you are starting a package, starting over on one, or preparing to inherit controls from a provider whose responsibility matrix you have not yet read closely, that is the moment where outside help pays for itself. Our approach to handling customer and program data is set out on our trust page, and you can reach our security practice through contact to talk through where your system sits in the sequence and what the realistic next step is.
Questions we get asked about this
FISMA is the Federal Information Security Modernization Act, which requires federal agencies and the contractors and providers operating systems on their behalf to run an information security program built on NIST standards. In practice, compliance means putting a system through the NIST Risk Management Framework and obtaining an authorization to operate from a government authorizing official. It is an ongoing obligation, not a one-time certification.
The RMF has seven steps: prepare, categorize, select, implement, assess, authorize and monitor. Prepare establishes the boundary, roles and risk tolerance; categorize sets the impact level; select and tailor the control baseline; implement builds and documents the controls; assess tests them; authorize is the risk acceptance decision; and monitor keeps that decision valid as the system changes.
It depends almost entirely on your system's impact level, how much you inherit from an authorized provider or common control program, and how mature your engineering and documentation practices already are. A moderate system inheriting heavily from an authorized platform moves far faster than a high system building most controls itself. The largest schedule risk is usually rework caused by a boundary or categorization decision that changes late.
FISMA is the underlying law and applies to federal systems and the systems operated on an agency's behalf. FedRAMP applies the same NIST control catalog specifically to cloud service offerings and adds a standardized authorization process with reuse across agencies. A cloud provider generally pursues FedRAMP; an agency system or a contractor-operated system generally pursues an agency ATO under FISMA.
The system owner, working with mission stakeholders, makes the call using FIPS 199 and NIST SP 800-60 guidance, and the authorizing official has to accept it. Engineers document the decision but should not make it alone, because it is fundamentally about mission impact. Record the rationale for each information type, since reviewers treat an unexplained rating as a guess.
A Plan of Action and Milestones tracks known weaknesses with an owner, a remediation approach and a target date. Authorizing officials read it closely because it tells them whether the program understands its own gaps and has resourced the fixes. Open items with no owner, or an implausibly empty POA&M, both undermine confidence in the rest of the package.
For most authorizations the assessment must be performed by a party independent of the team that implemented the controls, and program or agency rules may specify accreditation requirements. We deliver assessment work with accredited partners and keep our own role on the engineering, remediation and package preparation side. That separation avoids the conflict of an implementer grading their own implementation.
A significant change to the system — a new data type, a new external interconnection, a change to the authentication or cryptographic model, or a material architecture shift — requires a security impact analysis and may require reassessment of affected controls. Define what counts as significant in advance and make it visible to engineers. Routine continuous monitoring reporting handles everything below that threshold.
Bring us the process you were reading this for
Confidential assessment led by senior engineers. No obligation.