The Security Assessment (CA) domain is the "report card" for your security program. It is the "trust but verify" part of your program. While other domains establish controls, this domain requires you to test those controls. It moves security from a list of promises to a proven set of defenses.
You must create a plan to test your security controls. You must assess your systems to prove that your defenses meet your goals. You must also document these results in a formal report. Security is not a one-time event. You must watch your systems to detect changes or new threats. If you find a weakness, you must track it within a plan of action.
Your plan documents how you will fix the problem, who is in charge, and a remediation timeline. Checking your own work protects you against surprises found by an auditor or a hacker. You have evidence that your controls are effective. Leaders can make better decisions when they see clear reports on system risks. Tracking your fixes ensures that your security gets stronger every month.
Domain level policies address the controls implemented within systems and organizations. Policies are the perfect home to define control parameters, such as frequencies. Procedures describe the implementation of policies or controls. Organizations may document procedures within the system security plan or within separate documents. Here are some of the principles that guided this security assessment policy:
A cover page tracks specific details regarding the policy, including:
NIST SP 800-53 defines specific objectives for domain-level policies. From this guidance we incorporate the following major sections into our policy:
The purpose statement should identify why the policy exists and what it aims to achieve.
The scope should identify who it applies to and under what circumstances.
The policy governance section covers most of the organization defined parameters. These subsections cover the following details:
The fourth section includes our policy statements. Subsection headings group related Policy statements together. Each policy statement has a unique number for traceability to other documents. A policy statement number consists of the section, subsection, and policy statement order.
The fifth section identifies the relevant roles and responsibilities identified in the policy. A single, short paragraph describes the responsibilities for each role. The sixth section identifies the supporting procedures. We opted to align our subsection headings with the names of supporting procedures. The seventh section identifies related documents, to include relevant policies. The eighth section documents a revision history. This table captures policy changes, including: version, effective date, approver(s), change summaries. The ninth section captures a formal authorization of the policy by the policy owner.
NIST identified a named set of procedures for each practice within NIST SP 800-171. The assessment guide (SP 800-171A) contains the original mappings. The CMMC assessment guides include this mapping as well. The potential assessment methods and objects section contains a subsection called examine. Within each practice, NIST identified relevant policies, procedures and other artifacts. We used the relevant procedures to organize the section headings within each policy.
At a minimum, all security controls shall be reviewed and assessed for effectiveness at least once annually.
The organization shall employ independent assessors or assessment teams to conduct annual control assessments. To maintain impartiality, assessors shall be free from any perceived or actual conflicts of interest regarding the development, operation, or management of the systems under assessment. This independence may be achieved through the use of external third-party auditors (e.g., a 3PAO or C3PAO) or by utilizing internal personnel who do not have day-to-day operations or maintenance responsibilities for the controls being tested.
If a control is found to be ineffective or degraded, immediate action shall be taken to restore its functionality. The results of continuous monitoring activities, including any identified deficiencies, shall be reported to the CISO and relevant stakeholders to inform risk management decisions and update the Plan of Action and Milestones (POA&M).
CMMC Objectives Covered in This Section:
If a system vulnerability or a security control deficiency is discovered through assessments, continuous monitoring, or external audits, and an immediate solution is not available, the issue must be documented in a Plan of Action and Milestones (POA&M).
POA&Ms shall be developed and implemented to provide a structured approach for correcting system deficiencies and reducing or eliminating vulnerabilities. Each entry in the POA&M must include the planned remedial actions and the milestones for completion. The POA&M serves as the authoritative record for risk-based remediation and shall be used by the CISO to prioritize resource allocation for security improvements.
POA&Ms must be updated at least quarterly to reflect progress made toward remediation, record completed tasks, and adjust timelines for remaining deficiencies. This ensures that the organization maintains a transparent and proactive posture regarding its security gaps.
CMMC Objectives Covered in This Section:
Controls identified as having a higher risk of failure, or those protecting critical Controlled Unclassified Information (CUI), shall be subject to a more frequent monitoring schedule as defined and documented in the System Security Plan (SSP). Security controls shall be monitored on an ongoing basis by independent assessors or assessment teams to ensure their continued effectiveness in protecting organizational systems and data. This monitoring process involves impartial testing and verification, conducted by personnel with no direct responsibility for system operation or management, to ensure that controls are operating as intended and producing the desired outcome. Continuous monitoring activities shall focus on identifying systemic security flaws and ensuring that the organization maintains its established security baseline. The findings from these assessments shall be integrated into the annual Risk Assessment report.
CMMC Objectives Covered in This Section:
One or more System Security Plans (SSP) shall be developed and maintained to serve as the formal documentation of the organization’s security posture. Each SSP must clearly describe the system boundaries, the system environment of operation, and the relationships with or connections to other internal or external systems. The SSP shall include an accurate inventory of system components and a network diagram clearly illustrating CUI data flow and system boundaries.
The SSP shall detail how each NIST SP 800-171 security requirement is implemented within the environment. For any requirements identified as non-applicable, the SSP must provide a formal justification explaining why the control does not apply to the specific system or environment.
The SSP(s) shall be reviewed and updated at least annually or upon significant changes to the system environment. This review process must confirm that all security requirements are correctly applied and remain effective in protecting the information system. The SSP shall be updated as necessary to accurately reflect the current implementation of security controls.
The SSP shall be formally approved and signed by the CISO upon initial completion and after every major revision.
CMMC Objectives Covered in This Section:
FedRAMP guidance on how to write a control implementation statement states the following:
Write your policies before you start drafting your security plan. K2 GRC shows you exactly how each part of your policy connects to your security goals. This starts with selecting an objective to document.
After selecting a criteria, K2 GRC shows policy statements relevant to that criteria. The input screen shows the specific policy name and the statement’s number. This enables users to cite relevant policy sections within the control narratives. The system aggregates these control narratives to populate the system security plan (SSP).
Building a security program takes a lot of hard work, but without testing, how do you know it actually works?
It is stressful to wonder if a small mistake or a missed update has left your business open to a breach. You deserve to know that your hard work is paying off. Security Assessments replace that worry with facts. When you test your controls and track your progress, you gain more than a passing grade.
You gain the confidence that your data is safe and your team is ready. You stop reacting to problems and start leading with a clear vision. Don’t let the fear of a "bad report card" hold you back from greatness.
Our Security Assessment Policy template provides the framework to prove compliance. It takes the guesswork out of planning so you can focus on building a stronger, safer future.
