Your SSP and POA&M: What Assessors Actually Want to See

If you are preparing for a CMMC Level 2 assessment, two documents carry more weight than any other: your System Security Plan (SSP) and your Plan of Action and Milestones (POA&M). The SSP describes your environment and how you meet each security requirement. The POA&M tracks the requirements you have not met yet, along with how and when you will fix them. Get these two right and the rest of the assessment goes smoother. Get them wrong and the assessment can stall before it really starts.


This post is for the security or IT lead inside a defense contractor who has to build or clean up this paperwork. We will cover what each document must contain, what assessors look for, the common ways both documents fail, and what good documentation looks like in practice.


APT Security Management is a managed security services provider based in North Charleston, South Carolina. We prepare defense contractors for CMMC, so we see the same documentation problems over and over. Here is how to avoid them.

What is a System Security Plan, and why do assessors start there

The System Security Plan, or SSP, is the document that describes your information system and explains how you meet the security requirements that apply to it. For CMMC Level 2, that means all 110 security requirements from NIST SP 800-171.


The SSP is not optional, and it is not a formality. Under the CMMC scoring rules, you must have a current SSP in place at the time of the assessment that describes each information system within your assessment scope. If an up to date SSP is not there, the result is not a low score. It is a finding that the assessment could not be completed at all. That is the single fastest way to derail a Level 2 assessment, so the SSP is where assessors begin.

What your CMMC SSP has to cover

At a minimum, your SSP has to do the following, because these are the things the System Security Plan requirement itself calls for:

    Describe the system boundary, so it is clear what is in scope and what is not.

    Describe the system environment of operation, meaning where and how the system runs.

    Explain how each security requirement is implemented in your environment.

    Describe the relationships and connections to other systems.

    Identify any requirements that an authority has approved as not applicable.

    State how often the plan is updated, and show that it actually gets updated on that schedule.

    In practice, assessors also expect to see the artifacts that back those descriptions up. That usually means an asset inventory of the hardware, software, and accounts in scope, data flow diagrams that show where Controlled Unclassified Information (CUI) enters, moves, rests, and leaves, and clear descriptions of users and their roles. None of these stand alone. They exist so the boundary, the environment, and the implementation narrative are believable rather than asserted.

    The core of the SSP is the implementation narrative. For each of the 110 requirements, the plan has to explain how you meet it in your specific environment, with enough detail that someone could verify the claim. The narrative does not need to be a deep technical design document. It does need to be specific to you. A description that could describe any company is the same as no description at all. If you want to see how the 110 requirements line up against the NIST families, our post on how NIST 800-171 and CMMC Level 2 controls map walks through it.

    What is a POA&M, and why it is not a free pass

    The Plan of Action and Milestones, or POA&M, is the document that lists the security requirements you have not met, along with the planned fix, the person responsible, and the target completion date. For every requirement scored NOT MET, you are required to have a POA&M entry.


    Here is where many contractors misread the rule. A POA&M is not a way to get certified while leaving requirements undone. A requirement on a POA&M is still scored NOT MET. The POA&M is a remediation tracker, not a substitute for doing the work.


    You can earn a Conditional Level 2 status with some open items, but only under strict conditions. All of the following have to be true:

    Your assessment score divided by the total number of Level 2 requirements is at least 0.8. In plain terms, you need to have implemented at least 80 percent before a POA&M is even on the table.

    Only the lowest weighted requirements, the ones worth 1 point in the scoring methodology, can go on the POA&M. The higher weighted 3 point and 5 point requirements cannot be deferred. There is one narrow exception: if you are using encryption to protect CUI but it is not yet FIPS validated, that single item can sit on a POA&M.

    A short list of requirements can never go on a POA&M at all. That list includes controlling external connections, controlling public information, the three CUI physical access requirements, and, notably, the System Security Plan requirement itself. You cannot defer your SSP.

    If you meet those conditions, you get a Conditional CMMC Status. Then the clock starts. Every item on the POA&M has to be closed and verified by a separate POA&M closeout assessment within 180 days of the conditional status date. Miss that window and the conditional status expires.


    One more point worth stating plainly. At Level 1, none of this applies. A POA&M is not permitted at any time for Level 1. Every Level 1 practice has to be fully met. Level 1 is scored as met or not met in its entirety, with no partial credit and no deferral.

    Common ways an SSP fails an assessment

    Most SSP problems fall into a handful of patterns we see again and again:

      Vague control descriptions. The narrative restates the requirement instead of explaining how you actually meet it. "We control access to CUI" is not an implementation description. How, with what, applied to whom, is.

      Missing or fuzzy scope boundaries. If the boundary is not clearly drawn, an assessor cannot tell what they are assessing, and neither can you.

      No asset inventory. Without a list of the systems and accounts in scope, the boundary is just a claim.

      No data flow diagrams. If you cannot show where CUI goes, you cannot show that it is protected along the way.

      Copied and pasted templates. A generic SSP that does not reflect your real environment is easy to spot and tends to fall apart the moment an assessor asks a follow up question.

      Common ways a POA&M fails

      POA&M problems are usually less about the rules and more about hygiene:

      Stale items. Entries that have not been touched in months suggest the document is not being managed.

      Unrealistic dates. Target dates that have already passed, or that bunch every fix into the same far off week, do not hold up.

      No owner. Every item needs a named person responsible, not a department.

      No closure evidence. When an item is marked done, there has to be proof it was actually done. A status of "complete" with nothing behind it is not closure.

      What good documentation looks like

      Strong SSP and POA&M documentation shares four traits. It is specific, written about your environment rather than a generic system. It is current, reviewed and updated on a defined schedule rather than written once and forgotten. It is backed by evidence, meaning every claim can be tied to a policy, a configuration, a log, or a screenshot in final form rather than a draft. And it has clear ownership, so every requirement and every open item has a person attached to it.

      The goal is simple. An assessor should be able to read your SSP, understand your environment, and then go verify that what you wrote is true. Your POA&M should show a short, honest, well managed list of work in progress, not a dumping ground for everything you have not gotten to.

      How APT helps build or rebuild these documents

      Most contractors do not fail because they are careless. They fail because the documentation work is large, detailed, and easy to underestimate. APT helps in two ways. First, we run a gap assessment to find out where you actually stand against the 110 requirements, which is what feeds an accurate SSP and a realistic POA&M. You can read what to expect from a CMMC gap assessment before you start.

      Second, we help close the gaps, not just document them. Many of the requirements that show up as NOT MET need real tooling behind them, not just a paragraph in a plan. Audit logging gaps can be closed with endpoint and detection tooling from partners like Sophos. Boundary and network segmentation gaps can be addressed with products like those from Fortinet. Email security gaps can be handled with Proofpoint. The point is that the SSP narrative describes something real, because the control is actually in place.

      To be clear about our role: APT is your advisory and preparation partner, staffed with a Registered Practitioner (RP). We are not your C3PAO. The C3PAO is the independent organization that performs the certification assessment. We get you ready for that assessment. Our full approach is on the CMMC compliance prep page.

      What to Do Next

      Start by being honest about where your documentation stands. If you do not have an SSP, or the one you have was copied from a template, that is the first thing to fix, because the assessment cannot proceed without a real one. If you are not sure which requirements you actually meet, a CMMC gap assessment gives you the accurate picture that both documents depend on. From there, the SSP and POA&M become a record of real work rather than a wish list.

      Talk Through Your Situation With APT

      Not sure whether your SSP and POA&M would hold up in front of a C3PAO? Book a free 30 minute consultation and we will talk through your specific situation and where to start.

      Book a Free Consultation