03.12.01 Security assessment

03.12.01 asks you to assess your SP 800-171 requirements at a frequency you define and to show whether they are met. This page covers the test, the evidence and the cost.

On this page

What 03.12.01 security assessment asks for under NIST SP 800-171

Requirement 03.12.01 asks the organization to assess the security requirements for its system and its environment of operation at an organization-defined frequency, to determine whether those requirements are satisfied. In practice this is the organization's own periodic check of its implementation against SP 800-171 itself. It is not a one-time readiness exercise. If a contract requires SP 800-171, the compliance lead should expect the assessment to be repeated on a schedule the organization can defend, and should confirm with the contracting federal agency whether it has specified a frequency. When no frequency is specified, the organization must assign one, because NIST treats the frequency as an organization-defined parameter (ODP) that the nonfederal organization completes. Write the chosen value into the system security plan and the assessment plan so that an assessor can see where it came from.

The difficulty is that the requirement sets no fixed interval, so the organization has to justify its own. A useful starting point is to tie the frequency to events that change the picture: a major system change, a new external connection, a significant incident, a change in the CUI flow, or the end of a plan of action and milestones period. Scheduled cycles still matter, but they should be set alongside those triggers rather than substituted for them. The assessment also has to cover the environment of operation, not just the system boundary. That means the cloud accounts, identity providers, administrative workstations, backup locations, managed service providers and remote access paths that touch CUI. Teams often assess the application well and miss the surrounding environment, which is where many 03.12.01 findings come from.

Before committing to a schedule, the organization should decide who owns the assessment, who is independent of the controls being tested, and what the output looks like. The result of each assessment should be a written report that names the requirements tested, the method used, the findings and the owner of each finding, since those findings feed the POA&M under 03.12.02. Ask any implementation partner to show how the frequency, scope and report template will be recorded, and confirm in writing which parts of the assessment the organization will perform itself. DeployOpen can prepare the systems, configuration evidence and assessment records for this work, but the organization owns the decision on frequency and the assessment conclusions.

Which systems, teams and third parties a 03.12.01 assessment must cover

Before an assessment of 03.12.01 can be planned, the organization must decide what it is assessing. The boundary, the requirements in scope, the people who answer for security and the external providers the organization relies on each change how much evidence must be gathered and who must be interviewed. Each decision below sets the effort for the assessment that follows.

Draw the CUI system boundary

The assessment covers the system that stores, processes or transmits CUI and its environment of operation. Start by listing every place CUI flows, including endpoints, collaboration tools, backups and administrative consoles. A narrow boundary cuts the number of systems to test but only if CUI is kept out of the rest of the estate. Confirm the boundary against the system security plan before scoping the assessment, because an assessor will test whatever the documents say is inside it.

Define the environment of operation

03.12.01 asks for the assessment to cover the system and its environment of operation, not only the CUI system itself. Identity providers, logging pipelines, patch and configuration tooling and network controls that protect CUI are part of that environment. Each one added to scope adds configuration and log evidence to collect. Ask whether a shared service is in scope before the assessment plan is written, since reclassifying it later means reworking the sampling.

Set the assessment frequency

The one organization-defined parameter for 03.12.01 is the frequency of assessment, and NIST does not assign a value. If a federal agency specifies no value, the nonfederal organization must set one and document it. A shorter interval means more assessment cycles each year and more recurring evidence collection. Confirm with the contracting agency whether it expects a specific value before the organization commits to one in its policy.

Identify assessment and security personnel

The assessment requires interviews with personnel who hold security assessment responsibilities and with those who hold information security responsibilities. Names, roles and the authority each person holds must be recorded in the assessment plan. Interview time is one of the costs most often underestimated, especially when staff split their roles across IT operations and compliance. Confirm who will be available for interviews and whether any of them are contractors.

Trace controls held by external providers

Where the organization relies on a cloud provider, managed service or other external service provider for a control, the assessor will ask how that reliance is shown. The organization can cite the provider's own assessment results or contract terms, but it still owns the outcome for CUI. Gather those reports and contract clauses before testing starts. Missing provider evidence is one of the most common reasons an assessment slows down, so request it early.

Confirm the requirements in scope

Not every one of the 97 Rev. 3 requirements needs the same depth of testing, but the assessment must determine whether each in-scope requirement is satisfied. Decide which requirements the organization inherits from providers, which it implements itself and which it documents as not applicable with a reason. Each inherited requirement needs supporting evidence, and each exclusion must be defensible to an assessor. Record these decisions in the assessment plan so the scope is fixed before evidence collection begins.

How an assessor tests 03.12.01 under SP 800-171A

This table walks through how SP 800-171A Rev. 3 tests 03.12.01, from the single determination statement and the ODP check to the examine, interview and test objects an assessor looks at. Read it as a checklist of the artifacts and people your organization must be able to produce when the assessor asks for them.

Assessment elementWhat the assessor checksEvidence to have ready
Determination statementWhether the organization assesses its security requirements for the system and its environment of operation at the frequency it defined, to determine whether they are satisfied.A written assessment approach that names the system boundary, the environment of operation and the requirements in scope.
ODP checkWhether the assessment frequency is defined. SP 800-171A adds a separate determination statement for this, so an undefined frequency is a finding in its own right.A documented frequency value, the date it was approved and the owner who approved it.
Examine: policy and proceduresWhether a security assessment and monitoring policy and procedures exist and cover how assessments are run.Approved policy and procedure documents with version history and review dates.
Examine: assessment planWhether procedures exist for assessment planning and whether a security assessment plan defines scope, methods and responsibilities.A plan that lists the requirements, the system and environment assessed, the methods used and the assessors.
Examine: assessment reportWhether a security assessment report records results for the requirements, including the environment, and feeds corrective action.Dated reports covering the full boundary, including cloud, remote and third-party components, with findings and owners.
Interview: assessment personnelWhether people with assessment responsibilities understand the process, their role and how results are used.Named roles, short role descriptions and staff who can walk through a recent assessment.
Interview: information security personnelWhether information security staff know when assessments happen and how findings reach them.Evidence of hand-offs to remediation owners, such as tickets or plan of action entries.
Test: assessment mechanismsWhether the tools and processes that support assessments work as described, such as scanners, configuration checks or assessment tracking.Tool configurations, scan scope settings and a sample run that matches the documented process.
Common finding: undefined frequencyThe organization never assigned a value to the frequency parameter, so the requirement cannot be shown as met.Confirm the frequency value with your sponsoring agency or contract before the assessment begins.
Common finding: no assessment plan or stale reportsNo plan exists, or reports cover only part of the environment, such as on-premises systems but not cloud or remote endpoints.Scope statements that match the system security plan boundary, with reports that show each component was in scope.

Setting up a repeatable SP 800-171 assessment cycle

This sequence turns the 03.12.01 requirement into a schedule that produces the same kind of evidence each time, so the organization can show an assessor and its contracting agency that its security requirements are still being checked at the frequency it set. Each step hands a defined output to the next.

  1. Assign the organization-defined frequency

    Security leadership sets the frequency at which the security requirements for the system and its environment of operation will be assessed. 03.12.01 has one organization-defined parameter, and NIST does not assign its value. If a federal agency specifies the frequency in the contract or agreement, use that value; if it does not, the organization must assign one itself. The step is done when the frequency is written into the security assessment policy and the system security plan, and the owner of the schedule is named. Confirm with the contracting agency whether it expects a specific value.

  2. Define the assessment scope and plan

    Document which system, which boundary and which environment of operation the assessment covers, including enclaves, cloud accounts, endpoints and external service providers that touch CUI. Then write the security assessment plan, which lists the requirements to be assessed, the assessment methods (examine, interview and test as described in SP 800-171A Rev. 3), the evidence each method will draw on and the people responsible. The output is an approved plan that matches the system security plan boundary. Any mismatch between the plan and the boundary is resolved before testing starts.

  3. Select internal or independent assessors

    Choose who will perform the assessment. Internal staff can run it if they are independent of the people who operate the controls and have documented competence in the requirements. An independent assessor from outside the organization gives assurance that an internal team cannot, and is often expected when a contract requires a formal assessment. The selection is recorded with each assessor's role, independence statement and the scope they are authorized to test. Ask any outside firm to confirm in writing which assessment methods it will use and what it will deliver. Implementation partners may prepare evidence, but they should not assess their own work.

  4. Run the assessment against each requirement

    Assessors work through each requirement in scope using the determination statements in SP 800-171A Rev. 3. They examine policies, plans and configuration records, interview personnel with security assessment and information security responsibilities, and test mechanisms where the procedure calls for it. For each determination statement, the assessor records whether the requirement is satisfied, not satisfied or not assessed, with the evidence reviewed and the person interviewed. The step closes when every in-scope determination has a recorded result and a named evidence source.

  5. Record results in the security assessment report

    Consolidate the determinations into a security assessment report. The report lists each requirement, its result, the evidence and interviews behind the result, the assessor's name and the date of the assessment. Findings where a requirement is not satisfied are described in enough detail for the owner to fix them. The report is reviewed by the system owner for factual accuracy, but the assessor's findings are not changed to suit the owner. The output is a signed report that can be given to the contracting agency or retained for the next assessment cycle.

  6. Feed findings into the plan of action and milestones

    Transfer each unsatisfied requirement and each weakness from the report into the plan of action and milestones (POA&M), which is covered by sibling topic 03.12.02. Each entry gets an owner, a planned remediation action and a scheduled completion, and the POA&M is updated as items close. If the contract applies CMMC scoring, confirm with the relevant rules which requirements can appear on a POA&M, because 32 CFR 170.21 restricts some of them. The step is complete when every finding is either closed with evidence or tracked on the POA&M with an owner.

  7. Retain evidence and prepare for the next cycle

    Store the plan, report, assessor records, interview notes and POA&M history in a controlled repository with access limits, because these records are the evidence an assessor or contracting officer will request. Review what changed in the environment since the last cycle, such as new systems, cloud services or personnel, and update the scope before the next assessment starts. Confirm the retention period with the contract and the organization's records policy. The output is a dated evidence package and a scope change list that feed directly into the next run of this sequence.

Why 03.12.01 results drive the POA&M under CMMC Level 2

For a DoD contractor, the security assessment itself is a scored CMMC Level 2 practice. CMMC Level 2 still uses the Rev. 2 requirement set, so the practice that matches 03.12.01 is numbered 3.12.1 in Rev. 2 and appears as CA.L2-3.12.1 in the CMMC assessment guide. Under the 32 CFR 170.24 scoring methodology, that practice carries 5 points. Under 32 CFR 170.21, a practice of that weight cannot be placed on a plan of action and milestones (POA&M) to support Conditional status. In practical terms, an organization that has not completed its periodic assessment of the security requirements cannot treat the gap as a remediation item and still claim Conditional status. Confirm the current point values and POA&M rules against the eCFR text before you rely on them, since the rule is in active use and the DoD has issued related guidance in 2026.

This changes how the assessment has to be scheduled and documented. The assessment must exist as a completed, dated activity before the assessor arrives, with a security assessment plan that defines scope, frequency and methods, and a security assessment report that records what was examined, who was interviewed and what was tested. Treat the frequency value as a decision you make and record, because 03.12.01 leaves that frequency to the organization and a vague answer will not survive interviews. Ask your assessor, and the DoD point of contact where relevant, how they expect dates and evidence to be presented, and build the calendar so that the assessment is finished well ahead of any submission deadline.

The requirement itself changed only editorially from Rev. 2 to Rev. 3. NIST's change analysis traces 3.12.1 to 03.12.01 and classifies the change as not significant. That means a documented Rev. 2 assessment program largely carries over to Rev. 3 for this practice, which helps organizations that must plan for a future Rev. 3 transition. It does not mean the work is finished. Confirm which revision your contract and CMMC assessment reference at the time you assess, and keep the Rev. 3 determination statement wording in mind when you write procedures, so the evidence you collect can answer either revision.

Evidence that passes a 03.12.01 assessment

An assessor testing 03.12.01 reads documents and interviews people to confirm that assessments happen at a defined frequency and that results are recorded. The cards below cover the artifacts that carry that proof and how each one stays current between audits, so the evidence reflects the system as it is today rather than as it was at the last review.

Security assessment and monitoring policy

The policy states why the organization assesses its security requirements, who owns the assessment function, and how it relates to continuous monitoring and plans of action. Assessors start here because the policy defines the expectations the rest of the evidence must meet. Confirm that the policy names the frequency your organization assigned to the 03.12.01 organization-defined parameter, since NIST leaves that value to the nonfederal organization or the contracting agency. Review it on a set cycle and after any change to the assessment team or scope.

Assessment procedures and frequency record

Procedures describe how an assessment is planned, run, and reported, including the steps a reviewer follows. Keep a separate record showing how the assessment frequency was chosen, such as a decision memo that ties the interval to system change rate, threat exposure, or contract terms. Without that record, an assessor cannot confirm that the ODP value was deliberately set rather than copied from a template. Update the record whenever the frequency changes or the contract requires a different interval.

Security assessment plan

The assessment plan lists which of the 97 Rev. 3 requirements are in scope, the system boundary and environment of operation, the methods used (examine, interview, or test), and the people responsible. Assessors check that the plan covers the system that actually processes CUI, including cloud services and connected enclaves. Revise the plan when the boundary, the system security plan, or a major component changes, and record the version and approval date so the plan can be matched to the reports it produced.

Dated security assessment reports

Each assessment produces a report that records findings against each requirement, the evidence reviewed, the date of testing, and the assessor's conclusion on whether the requirement is satisfied. The report is the core artifact of 03.12.01, and gaps found here feed the plan of action and milestones. Keep every report, including those with no findings, and never overwrite a prior report. Dated, versioned reports show a history of assessment at the defined frequency, which is what an assessor tests for.

Assessor and reviewer records

Assessors look for records that name who performed each assessment, who reviewed the results, and whether those people had the skills and independence the organization requires. Maintain a roster with roles, training, and any conflicts, and keep sign-off records for each report. Where an internal team performs the assessment, the reviewer should not be the person who configured the system under test. Update the roster whenever staff change so that interviews in an audit match the records.

Tool output supporting the assessment

Scanner and configuration output can show that specific checks ran on a given date, but it does not replace the assessment report. Wazuh Security Configuration Assessment scans endpoints against YAML policies and recommends remediation, and Fleet policies show which devices pass or fail each osquery check. Retain exported results with timestamps and the policy version used, and confirm that each tool's coverage matches the assessment scope before presenting its output as assessment evidence.

What meeting 03.12.01 costs in money and effort

The largest cost for most organizations is staff time. 03.12.01 asks for the security requirements to be assessed at a defined frequency, and SP 800-171A Rev. 3 expects an examination of the assessment policy, the assessment plan and the assessment report, plus interviews with the people who hold assessment and security responsibilities. Someone must set the frequency, prepare the plan, gather evidence and write the report. That work is paid for in salaries or contractor hours, and it recurs every assessment cycle.

  • Frequency setting: the organization must assign the value for the frequency ODP. A shorter cycle multiplies the hours spent on each assessment.
  • Scope size: the number of systems, enclaves and external service providers inside the CUI boundary drives the evidence volume.
  • Evidence readiness: teams that collect configuration and log evidence continuously spend less time reconstructing it before each assessment.
  • Role overlap: if the same people build controls and assess them, independence is weaker and more rework is likely.
  • Quote request: ask the implementation partner to state assumed staff roles, hours per role and the number of assessment cycles covered.

Confirm with your own finance and security leads how these hours are costed, since no external figure for this effort is supplied.

Where 03.12.01 assessments usually fall short

Most weak security assessments fail on paperwork and scope rather than on technical depth. The gaps below cluster around four questions: how often assessments happen, what they cover, who signs off, and whether findings lead to tracked remediation.

No frequency set for the assessment

03.12.01 has one organization-defined parameter: the frequency at which the security requirements are assessed. SP 800-171A Rev. 3 includes a determination statement that checks this value is defined, so a blank or vague entry such as "periodically" fails on its own. Fix: write a specific interval into the system security plan, tie it to change events such as a major system change or a new CUI flow, and record the date of each completed assessment against it.

Assessment stops at the system boundary

The requirement covers the system and its environment of operation, so an assessment that checks servers and applications but skips identity providers, administrator workstations, backup services and hosting accounts leaves part of the requirement untested. Assessors often ask who manages each component and whether it was included. Fix: list every component that stores, processes or transmits CUI or manages access to it, inside and outside your accounts, and map each one to the assessment plan.

Reports without owner or date

An assessment report that names no assessor, lacks a date, or does not state which requirements were tested cannot show that 03.12.01 was met at a point in time. Assessors examine the security assessment report as evidence, and interviews check that the people named in it have the responsibility claimed. Fix: give every report a version number, a named assessor, a scope statement listing the requirements tested, the test methods used, and sign-off by the accountable official.

Findings missing from the POA&M

Weaknesses found during an assessment that never reach a plan of action and milestones are a frequent gap, because the assessment and remediation records sit in different tools. The sibling requirement 03.12.02 handles that record, and the CMMC scoring rules treat POA&M eligibility as a constrained decision. Fix: route every unmet determination into a tracked item with an owner, a planned completion date and the requirement it affects before the report is closed.

Assessors lacking independence

When the people who built or operate a control also grade it, the result carries little weight with a contracting officer, an auditor or a DoD assessor. Independence depends on the organization's own risk appetite and contract terms, so confirm the requirement with the agency or prime contractor before choosing who assesses. Fix: separate the assessor from the control owner for at least the annual review, document the reasoning for each choice, and ask any outside party to state its own qualifications in writing.

Automated results never reviewed

Configuration scanners and endpoint policy tools produce pass and fail results continuously, but a dashboard that nobody reviews is not an assessment. Wazuh Security Configuration Assessment and Fleet policies both report results that someone must interpret, decide on and retain. Fix: name a reviewer for each scanner, record the periodic review in the assessment plan, and keep exported results with the date and the reviewer's notes as supporting evidence.

Common questions about the 03.12.01 security assessment

How often do we have to assess our security requirements under 03.12.01?

03.12.01 requires assessment at an organization-defined frequency, so the organization sets the interval itself. That value is the single organization-defined parameter for this requirement, and SP 800-171A Rev. 3 includes a determination statement that checks the value has actually been defined. Leave the frequency blank and the requirement is not complete. When choosing the interval, check the contract, the agreement with the federal agency and any sponsor terms first, because they may specify a frequency or a trigger. Without that, document a rationale tied to how quickly your system and threat picture change, and reassess after significant changes such as a new boundary, a major platform upgrade or a new CUI flow. Confirm the expected interval with your contracting officer or sponsor before you write it into the system security plan.

Can our internal staff perform the 03.12.01 security assessment?

Yes, the requirement does not require an outside party, and most organizations start with internal staff who understand the system. The work still needs independence from the people who run the controls, a written assessment plan, documented methods and a written report that records findings. Internal assessors should use the examine, interview and test methods described in SP 800-171A Rev. 3 and keep their evidence organized by requirement. Whether an external review is needed depends on the contract and on the assessment type that applies to you. A self-run assessment does not produce a DoD assessment score or certificate, and only an independent assessor or the government body named in the contract can issue those results.

What does the organization have to provide for a 03.12.01 assessment?

The organization owns the assessment and must supply the inputs an assessor will test. The core items are:

  • A current system security plan that defines the system boundary, the environment of operation and the controls in place
  • Written security assessment and monitoring policy and procedures, plus an assessment plan that states scope, methods and responsibilities
  • Access to configuration records, logs, scan results and tickets that show controls operate
  • Named personnel with assessment and information security responsibilities who can answer interview questions
  • A written assessment report, with findings tracked into a plan of action and milestones where weaknesses remain

The organization also decides the assessment frequency and records it. An implementation partner can prepare these artifacts and test the environment before the assessor arrives, but the controls and the decisions remain with the organization.

How long does a 03.12.01 security assessment take?

Duration depends on the scope: the number of systems in the boundary, the number of enclaves, how much evidence already exists and how many people must be interviewed. No duration figure applies to every environment, so ask for a timeline built from a written scope rather than a general estimate. Large, heterogeneous environments with many interfaces and undocumented controls take longer than a single, well-documented enclave. Preparation time is often the largest variable, because gaps found during a first pass must be fixed before an assessor can test them. Ask any provider to break the timeline into scoping, evidence collection, testing, reporting and remediation, and to state which of those steps you own.

Does the Rev. 2 or Rev. 3 choice change how we run the 03.12.01 assessment?

The core intent is the same, but the numbering and the assessment method differ. NIST's change analysis traces 03.12.01 to Rev. 2 requirement 3.12.1 and classifies the change as editorial only. The practical difference is in the scoring and the contract. DoD contractors are assessed against the 110 Rev. 2 requirements through CMMC Level 2, where the identifier is CA.L2-3.12.1, and the Rev. 2 text remains the baseline named in current DoD guidance. Rev. 3 uses 97 requirements and organization-defined parameters that you must assign. Confirm which version your contract, agreement or sponsor requires before you plan the assessment, because an assessment run against the wrong version may not satisfy the obligation.

What does an independent assessor add to our 03.12.01 work?

An independent assessor adds objectivity and a result the customer or regulator can rely on. Internal reviews can miss gaps because staff are close to the controls and may read their own evidence generously. An assessor applies the methods in SP 800-171A Rev. 3, tests whether controls operate as described, interviews staff and produces a report with findings you can act on. Where a contract requires a formal DoD assessment, an assessor certified or authorized for that purpose performs the work. Ask any firm to state its credentials for the assessment type you need, to confirm what it will deliver and whether it issues any score or certificate, and to explain how it handles findings that must go into your plan of action and milestones.

Which tools can help produce evidence for a 03.12.01 assessment?

Tools help collect and organize evidence, but they do not perform the assessment or decide compliance. CISO Assistant, licensed under AGPL-3.0-only, can run audits and compliance assessments against many frameworks and maps between them, which helps track requirements and evidence in one place. Wazuh, under GPL-2.0-only, includes Security Configuration Assessment that scans monitored endpoints with YAML policies and reports misconfigurations, giving you configuration evidence for the environment. Fleet, under the MIT license, runs yes or no osquery policies on devices and shows which devices pass or fail, which supports continuous evidence. Confirm that any tool's policies cover the settings your own system security plan commits to, because default policies rarely match a specific boundary exactly.

Who is responsible if the 03.12.01 assessment is done wrong?

The organization is responsible for its own compliance, and NIST states that application, implementation and compliance issues rest with the federal agency that holds the contract or agreement with the nonfederal organization. An implementation partner or assessor can be contracted to prepare evidence or test controls, but that does not transfer the obligation. Your contract should define what each party delivers, what standard applies and how findings are handled. Keep the written scope, the assessment plan and the report so you can show who did what and when. If a finding is not fixed, record it in a plan of action and milestones rather than leaving it undocumented.

How DeployOpen prepares 03.12.01 assessment evidence

DeployOpen's part in 03.12.01 starts with a written, fixed scope that names the system boundary, the environment of operation, the assessment frequency the organization has chosen for the ODP, and who owns each assessment activity. Because 03.12.01 has a single organization-defined parameter, the frequency, that value has to be set and documented before any evidence is gathered. Where a federal agency has not specified it, the organization assigns it, and we recommend confirming the value in the contract or agreement before work begins. The scope document also lists the systems to be prepared, the security testing to be run, and the deliverables, so the organization can check each item against the assessment procedure in SP 800-171A Rev. 3.

In practice, preparation means making the assessment repeatable. We configure the platforms that produce evidence, such as CISO Assistant for mapping requirements to controls and recording assessments, Wazuh for configuration assessment against endpoint policies, and Fleet for yes or no policy checks across devices, and we document how each output is exported and retained. We also help draft the security assessment policy, the procedures for assessment planning, and the assessment plan and report templates that an assessor will examine and interview against. Security testing of applications, APIs, cloud and infrastructure can be scheduled inside the same scope so its results feed the assessment record. Ask the organization's staff to confirm which personnel hold assessment responsibilities, since the interview objects in SP 800-171A depend on them.

DeployOpen does not issue assessment reports, attestations or certifications. The organization owns its controls and the determination of whether 03.12.01 is satisfied, and an independent assessor, or the assessing body the contract requires, produces the findings. Our deliverables are the prepared systems, documented procedures, test results and evidence packages, handed over under the written scope. Before engaging, ask any prospective partner to confirm in writing which deliverables it prepares, which it does not, and how the contracting agency's assessment requirements are reflected in the agreed scope.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.