5.1 Security Assessment Plan (SAP) & Assessor Independence

5.1 Security Assessment Plan (SAP) & Assessor Independence

Within the NIST Risk Management Framework (RMF) and the ISC2 CGRC body of knowledge, Step 4: Assess bridges technical security engineering with executive risk decision-making. The primary purpose of control assessment is to determine the extent to which security and privacy controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security and privacy requirements of the system.

To conduct a disciplined, repeatable, and legally defensible assessment, organizations develop a comprehensive Security Assessment Plan (SAP) governed by NIST Special Publication 800-53A Revision 5 (Assessing Security and Privacy Controls in Information Systems and Organizations). The SAP serves as the formal operational contract between the assessment team, system owners, and authorizing officials.

---

RMF Step 4: Assess Overview and Life Cycle Tasks

NIST SP 800-37 Rev. 2 defines six discrete tasks within Step 4 (Assess):

┌─────────────────────────────────────────────────────────────────────────────┐
│                        RMF STEP 4: ASSESS WORKFLOW                          │
│                                                                             │
│  Task A-1: Appoint Independent Assessor (SCA)                              │
│      │                                                                      │
│      ▼                                                                      │
│  Task A-2: Develop Security Assessment Plan (SAP) & Rules of Engagement     │
│      │                                                                      │
│      ▼                                                                      │
│  Task A-3: Authorizing Official (AO) Approves SAP                           │
│      │                                                                      │
│      ▼                                                                      │
│  Task A-4: Execute Assessment (Examine, Interview, Test)                   │
│      │                                                                      │
│      ▼                                                                      │
│  Task A-6: Initial Remediation & Rescan (Optional Window)                  │
│      │                                                                      │
│      ▼                                                                      │
│  Task A-5: Finalize Security Assessment Report (SAR)                       │
└─────────────────────────────────────────────────────────────────────────────┘

---

Purpose and Structure of the Security Assessment Plan (SAP)

The Security Assessment Plan is an actionable engineering and operational document. It establishes the testing boundary, specifies which controls will be tested, defines the evidence required, and outlines logistical constraints.

Core Structural Components of a Compliant SAP

1. Assessment Purpose and Objectives:

   • Articulates the formal driver for assessment (e.g., initial authorization, periodic re-assessment, significant architectural change, FedRAMP continuous compliance).
   • Establishes the standard of review (e.g., NIST SP 800-53 Rev. 5 Moderate baseline).

2. System Identification and Assessment Scope:

   • Defines the exact authorization boundary, including all hardware assets, virtual machines, cloud instances, interconnected external services, sub-systems, APIs, and data repositories.
   • Explicitly lists components that are in-scope and out-of-scope (e.g., third-party managed WAN transport or inherited common controls assessed under separate packages).

3. Assessment Team Roles and Responsibilities:

   • Identifies the Security Control Assessor (SCA), Lead Assessor, technical vulnerability testing personnel, and privacy analysts.
   • Documents the lines of authority and confirms that team credentials match the technical stack.

4. Assessment Schedule and Milestones:

   • Establishes a synchronized timeline for documentation review, personnel interviews, technical scanning, physical site visits, draft findings briefing, and final report delivery.

5. Assessment Procedures and Control Cases:

   • Translates NIST SP 800-53A assessment objectives into specific assessment cases.
   • Identifies the assessment methods (Examine, Interview, Test) and specific assessment objects (Specifications, Mechanisms, Activities, Individuals) to be utilized for each control enhancement.

6. Evidence Artifact Requirements:

   • Itemizes mandatory evidence files: System Security Plan (SSP), Contingency Plan (CP), Incident Response Plan (IRP), configuration baselines, patch logs, database hardening scripts, training rosters, and cryptographic certificates.

---

Scoping the Level of Effort and Auditing Existing Evidence

Two SAP inputs decide whether an assessment is affordable and whether it wastes money re-proving what was already proven: the level of effort and the pre-existing evidence the team may legitimately rely on. CGRC task 5.1 names both explicitly — "Assets, methods, and level of effort scoped" and "Evidence for demonstration of compliance audited."

Scoping the Level of Effort (LOE)

Level of effort converts the scoped asset list and the chosen assessment methods into a defensible estimate of assessor hours, calendar duration, and cost. This is not a scheduling nicety. An under-scoped assessment either overruns the authorization deadline or silently reduces depth and coverage — and both outcomes mislead the Authorizing Official about how much assurance the SAR actually carries.

Four drivers govern LOE:

Sampling deserves particular attention. Assessors rarely test every instance of an asset class; they define a representative sample sized to the impact level and justify that sample in the SAP. A sample chosen for convenience rather than representativeness — three development servers standing in for a production fleet — is a methodological defect that undermines the SAR no matter how many hours were spent.

[!NOTE] The LOE trap. When the schedule is fixed and scope grows, something has to give. The governance-correct response is to document the reduced coverage as a stated limitation in the SAP and SAR so the AO knows exactly what was not assessed. The wrong response — quietly narrowing the sample and reporting the result as a full assessment — manufactures false assurance and is the assessment equivalent of an unreported POA&M item.

Auditing Evidence Before Testing Begins

Before the team executes a single procedure, it audits the compliance evidence that already exists. This pre-assessment review establishes the documented state of the system and identifies where prior work can legitimately reduce new testing.

Three categories of evidence matter:

1. Previous assessments and audits — the last SAR, prior 3PAO reports, Inspector General or internal audit findings, penetration test reports, and the open POA&M. These show where deficiencies historically cluster and expose findings that were closed on paper but never independently verified.
2. System documentation — the SSP and its control implementation statements, network and data-flow diagrams, configuration baselines, contingency and incident response plans, and interconnection agreements. Documentation that contradicts the deployed system is itself a finding.
3. Policies and procedures — organizational policy, standard operating procedures, and the training and awareness records that indicate whether the written policy is actually operating.

Reuse has limits, and the exam tests them. Existing evidence may be relied upon only when it is current, relevant to the control as it is now implemented, and produced by a source with adequate independence. A vulnerability scan from eleven months ago does not demonstrate today's patching posture. A prior assessment of a control that has since been re-architected proves nothing about the new implementation. A system owner's self-assessment cannot substitute for the independent testing required at Moderate and High impact levels. Where evidence is stale, no longer relevant, or insufficiently independent, the control is reassessed.

The correct sequence is therefore: audit the existing evidence first, use what survives that audit to inform scope, methods, and level of effort, and only then finalize the SAP — never the reverse.

---

Rules of Engagement (RoE)

A critical element of the SAP—especially when technical testing, vulnerability exploitation, or penetration testing is involved—is the Rules of Engagement (RoE). The RoE acts as the operational and legal safeguard protecting the production availability and data integrity of the target environment.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     RULES OF ENGAGEMENT (RoE) PILLARS                       │
│                                                                             │
│  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐  │
│  │    Testing Windows    │ │ Communication Protocol│ │  Emergency Stop   │  │
│  │  • Maintenance hours  │ │  • Daily status call  │ │  • Cease testing  │  │
│  │  • Freeze periods     │ │  • Critical alerts    │ │  • System restore │  │
│  │  • Off-peak execution │ │  • Designated POCs    │ │  • Root analysis  │  │
│  └───────────────────────┘ └───────────────────────┘ └───────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │                 Prohibited Assessment Activities                      │  │
│  │  • Denial of Service (DoS) attacks                                    │  │
│  │  • Permanent data destruction or alteration                           │  │
│  │  • Modifying active production credentials or root lockouts           │  │
│  │  • Exceeding defined IP ranges and domain boundaries                  │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

Essential RoE Provisions

• Authorized Testing Windows: Specifies permissible testing hours (e.g., "Technical scanning permitted only between 22:00 and 04:00 UTC on weekends") to avoid disrupting business operations.
• Designated Points of Contact (POCs): Identifies primary and alternate operational escalation contacts, including System Administrators, the Information System Security Manager (ISSM), the Network Operations Center (NOC), and the Security Operations Center (SOC).
• Emergency Stop ("Cease Testing") Procedures: A mandatory protocol stating that if testing causes system instability, network latency spikes, service outages, or data corruption, the assessment team must immediately halt all testing, notify the lead POC within 15 minutes, and document the exact command or test case executed.
• Critical Vulnerability Immediate Notification: Mandates that if the assessment team discovers an active, exploitable critical vulnerability (e.g., an unauthenticated remote code execution flaw or evidence of an ongoing adversary intrusion), the finding must be escalated within hours rather than waiting for the final SAR.
• Scope Constraints and Prohibited Activities: Formally outlaws destructive techniques, distributed denial-of-service (DDoS) simulations against production pipelines, physical destruction, and unapproved social engineering.

---

Assessor Independence and Impartiality

To ensure that the Authorizing Official (AO) receives an objective, credible, and unvarnished appraisal of system risk, the assessment must be executed by an Independent Assessor.

[!IMPORTANT] NIST SP 800-37 Rev. 2 Independence Rule: Assessor independence is defined as the freedom from operational, financial, or developmental conflicts of interest that could impair the assessor's ability to render an unbiased, objective evaluation of security and privacy controls.

Strict Conflict of Interest (COI) Boundaries

Assessors are deemed non-independent and disqualified if they:

1. Designed, engineered, or developed the information system architecture.
2. Implemented, configured, or integrated the security controls being assessed.
3. Serve as the day-to-day operational manager, Information System Owner (ISO), or Information System Security Officer (ISSO) for the system.
4. Fall under the direct operational command of the system owner (e.g., subordinate reporting relationships where negative audit findings could result in career reprisal).
5. Have a direct financial stake in the certification outcome or system procurement.

Levels of Assessor Independence

Independence Requirements by FIPS 199 Impact Level

• Low-Impact Systems: May utilize internal assessors with administrative independence (e.g., an assessor from an adjacent department within the organization).
• Moderate-Impact Systems: Requires independent internal assessors or external third parties with no developmental or operational ties to the system.
• High-Impact Systems: Demands a rigorous, fully independent assessment team (often external third-party or dedicated agency audit corps) to provide maximum assurance to the AO.

---

Tailoring Assessment Procedures

Not all controls require the same depth or frequency of assessment. Assessors must tailor the baseline assessment procedures in NIST SP 800-53A Rev. 5 using structured criteria:

1. Scoping and Boundary Adjustments: Omitting assessment cases for controls that have been formally scoped out or scoped as non-applicable during RMF Step 2 (e.g., wireless controls AC-18 for systems with no wireless capability).
2. Common Control Inheritance: If a control is designated as a Common Control provided by an enterprise entity (e.g., physical security PE-3 provided by the facility management office or identity management IA-2 provided by corporate Active Directory), the system assessor verifies the inheritance and relies on the Common Control Provider's (CCP) assessment report rather than re-testing the control from scratch.
3. Compensating Controls: Developing specialized assessment procedures to verify that alternative safeguards provide equivalent protection to the baseline requirement.
4. Assurance Level Alignment: Increasing the depth of examination and testing (e.g., manual source code audits and fuzz testing) for high-risk mission-critical components.

---

Real-World RMF Scenario: Assessor Independence Dispute

Scenario: A commercial healthtech company prepares its electronic health record (EHR) platform for federal agency authorization at the FIPS 199 Moderate impact level. The engineering vice president assigns the lead DevOps architect who built the automated AWS infrastructure to lead the security assessment and author the SAR, arguing that no one understands the Terraform configurations better.

GRC Action: The agency Authorizing Official Designated Representative (AODR) immediately rejects the proposed assessment plan. Having the lead infrastructure architect assess their own configurations creates a severe Conflict of Interest (COI) and eliminates assessor independence. The agency mandates the appointment of an independent third-party assessment organization (3PAO) or an unassociated internal audit team to draft the SAP and conduct testing, ensuring the AO receives an uncompromised risk evaluation.

---

Common Exam Traps

• ⚠️ Trap: Assuming the Information System Security Officer (ISSO) can serve as the formal independent assessor. The ISSO is responsible for day-to-day security operations and control maintenance, creating an immediate conflict of interest.
• ⚠️ Trap: Confusing the Security Assessment Plan (SAP) with the System Security Plan (SSP). The SSP (developed in RMF Step 2/3) documents how controls are implemented, while the SAP (developed in RMF Step 4) documents how controls will be tested and evaluated.
• ⚠️ Trap: Believing the assessment team can unilaterally begin testing without executive sign-off. The Authorizing Official (AO) or designated representative must review and approve the SAP and RoE before active testing begins.