SA-11(7): Verify Scope of Testing and Evaluation

This control enhancement sits in the System and Services Acquisition (SA) family and focuses on a recurring failure mode: teams run testing, generate a report, and still miss required controls because the scope was incomplete or the rigor was too low for the system’s risk posture. SA-11(7) forces an explicit verification step by the developer that the testing and evaluation scope fully covers required controls at the rigor your organization specifies. ¹

For a Compliance Officer, CCO, or GRC lead, the practical question is: how do you convert this into a repeatable acceptance gate that works across internal development and third-party development? The answer is to treat scope verification as a contractable, reviewable artifact set: a traceability matrix that ties each required control to specific test cases and results, plus a rigor statement that matches your program requirements.

This page gives requirement-level implementation guidance you can apply immediately: applicability, a step-by-step procedure, evidence to retain, common audit questions, and a practical execution plan that fits real engineering workflows and third-party delivery.

Regulatory text

Requirement (verbatim excerpt): “Require the developer of the system, system component, or system service to verify that the scope of testing and evaluation provides complete coverage of the required controls at the following level of rigor: {{ insert: param, sa-11.7_prm_1 }}.” ¹

Operator meaning: You must (1) define what “required controls” are for the system/component/service, (2) define the “level of rigor” your program expects, and (3) make the developer responsible for verifying, in writing and with traceable support, that testing and evaluation cover all those controls at that rigor. Your job is to enforce this as an entry/exit criterion for deployment, acceptance, or authorization.

Practical translation: “Show me the list of required controls, show me the tests that cover each one, show me the results, and show me that the testing method was strong enough for this system’s risk.”

Plain-English interpretation (what SA-11(7) really demands)

SA-11(7) is a scope completeness control. It is not asking you to “do more testing” generically. It is asking you to prevent blind spots by forcing a verification that:

• Nothing required is missing from test scope (complete coverage of required controls).
• The testing depth matches your defined rigor (for example: basic functional checks vs. adversarial testing, or design review vs. implementation testing, depending on your rigor definition).

The “developer” can be:

• An internal engineering team.
• A systems integrator.
• A software supplier.
• A cloud/service provider delivering a system service.

Your acceptance gate should not depend on trust. It should depend on traceability and reviewable artifacts.

Who it applies to (entity and operational context)

You apply SA-11(7) anywhere you rely on a developer to build, configure, integrate, or materially change a system, component, or service that must meet a defined control baseline.

Common contexts:

• Federal information systems subject to NIST SP 800-53 control selection and assessment expectations. ²
• Contractor systems handling federal data where the program requires NIST SP 800-53-aligned controls and evidence as part of delivery and authorization. ¹
• Major releases / significant changes where testing scope can drift (new features, new infrastructure, new identity flows, new logging pipeline).
• Third-party provided components/services (commercial software, managed services) where you receive testing outputs but need confirmation of what was actually covered.

What you actually need to do (step-by-step)

Treat SA-11(7) as a documented “scope verification workflow” that runs before acceptance.

Step 1: Define “required controls” for the system

1. Identify the system boundary and in-scope components/services.
2. Confirm the control baseline and any overlays, tailoring, or inheritance assumptions.
3. Produce a Required Controls List for this system (or component/service), with control IDs and short statements of what “implemented” means in your environment.

Output: “Required Controls List” (owned by GRC/ISSO/Control Owner group, approved by system owner).

Step 2: Define the “level of rigor” you expect

SA-11(7) includes a parameter placeholder for rigor. Your program must set it. ¹

Make it operational by defining:

• Minimum test methods acceptable (e.g., document review, interview, technical test).
• Minimum independence expectations (developer self-test vs. independent test, if your program requires it).
• Minimum depth for high-risk controls (for example: authentication, logging, access control).

Output: “Testing and Evaluation Rigor Standard” (a short standard you can attach to SDLC, procurement, and ATO gates).

Step 3: Require a control-to-test traceability matrix from the developer

In your SDLC or third-party delivery terms, require the developer to deliver a Controls Coverage Matrix that maps:

• Required control → implementation location (where in code/config/process it exists) → test cases → evidence → results.

Your acceptance criterion: every required control has at least one mapped test activity that meets your rigor standard, or has an approved rationale for inheritance/exclusion.

Output: “Controls Coverage Matrix” (developer-produced, GRC reviewed).

Step 4: Verify completeness (scope verification review)

Perform a structured review. Don’t “spot check” randomly.

Recommended review checklist:

• Are all required controls present in the matrix, with no omissions?
• Are inherited controls clearly marked, with the inheritance source identified?
• Do test cases actually validate the control objective, or only verify a related function?
• Are there any “paper-only” controls with no test evidence?
• Does the test method match the rigor standard for that control?

Output: “Scope Verification Memo” or ticket approval record stating coverage is complete at defined rigor, with exceptions documented.

Step 5: Handle exceptions explicitly (don’t let them hide in narratives)

You will find gaps. Decide how you treat them:

• Stop-ship: release blocked until coverage exists.
• Conditional acceptance: time-bound remediation with risk acceptance.
• Inherited control proof: evidence from platform/provider replaces testing.

Create an Exceptions Register tied to the system risk register, with owner, due date, and compensating controls, if any.

Step 6: Gate acceptance and retain artifacts

Make SA-11(7) a release condition:

• No production release (or no authorization milestone) without a completed Controls Coverage Matrix and signed scope verification record.

If you use a GRC tool, store artifacts and link them to the control statement. If you manage evidence in tickets and repositories, define a consistent folder structure and naming convention.

Step 7: Repeat on change, not only annually

Scope becomes stale after meaningful change: new identity provider, new logging vendor, new network segmentation model, new data flow. Your change process should trigger a re-verification of scope for affected controls.

Required evidence and artifacts to retain

Auditors will ask for proof that verification happened and that it covered required controls at the defined rigor. Keep these artifacts:

Core artifacts (minimum)

• Required Controls List for the system/component/service.
• Testing and Evaluation Rigor Standard (program-level).
• Controls Coverage Matrix (control → test mapping).
• Test plans/procedures that correspond to mapped tests.
• Test results and raw evidence (logs, screenshots, tool outputs), or references to where it is immutably stored.
• Scope Verification Memo / approval ticket with reviewer, date, and any exceptions noted.

Supporting artifacts (strongly recommended)

• System boundary diagram and inventory of in-scope components.
• Inheritance documentation for shared controls (e.g., platform logging).
• Exceptions Register entries with risk acceptance approvals.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you know testing covered every required control, not just a subset.”
• “Where is the defined rigor standard, and how is it applied per control?”
• “What happens when a developer claims a control is inherited? Show the inheritance source.”
• “How do you prevent controls from being marked compliant without corresponding test evidence?”
• “Demonstrate that this process is repeatable across systems and releases.”

Common hangup: teams produce a penetration test report and treat it as “coverage.” Pen tests rarely map to every required control. Your matrix must show coverage for each required control, using appropriate methods.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating the test plan as proof of coverage.
Fix: require the control-to-test mapping plus results; a plan alone proves intent, not coverage.

Mistake 2: Vague rigor language (“tested thoroughly”).
Fix: write a rigor standard you can audit against, and require developers to state which methods were used per control.

Mistake 3: Mixing system scope and component scope.
Fix: define boundaries first. For a component/service, explicitly document which controls are the developer’s responsibility vs. the integrator’s.

Mistake 4: Inheritance hand-waving.
Fix: require inherited controls to cite the inheritance source and attach supporting evidence or an authorization package reference.

Mistake 5: Evidence stored in ephemeral tools.
Fix: define where artifacts live, how they are retained, and how you can reproduce them during an exam.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat it as a compliance and assurance expectation rather than an enforcement-cited rule in this write-up.

Operational risk is still real: incomplete testing scope produces unknown control failures that surface during authorization, customer assessments, incidents, or supplier disputes. If a third party builds a component and cannot show control-level test coverage at your required rigor, you inherit hidden risk and may fail internal or external assurance reviews.

Practical 30/60/90-day execution plan

Day 1–30: Stand up the requirement as an acceptance gate

• Assign an owner (GRC lead or security assurance lead) for SA-11(7) implementation.
• Publish a one-page “Testing and Evaluation Rigor Standard” aligned to your program’s rigor expectation. ¹
• Create templates: Required Controls List, Controls Coverage Matrix, Scope Verification Memo.
• Update SDLC or procurement checklists so releases cannot close without scope verification artifacts.

Day 31–60: Pilot on one system and one third party

• Run the workflow on a live system with an upcoming release.
• Run it on a third-party delivered component/service with a contract deliverable: require the matrix and verification statement.
• Capture gaps and refine templates (common missing controls, confusion about inheritance, missing raw evidence).

Day 61–90: Scale and operationalize

• Train engineering managers, QA, and security testing teams on how to fill the matrix without creating busywork.
• Integrate into change management: changes that affect controls trigger a scope re-verification.
• Centralize evidence collection. Daydream can help by mapping SA-11(7) to a named control owner, a repeatable procedure, and recurring evidence artifacts so you can request the same proof set across teams and third parties without rewriting requirements each time. ¹

Frequently Asked Questions

Does SA-11(7) mean the developer must test every control personally?

No. It means the developer must verify the testing and evaluation scope covers all required controls at the required rigor, including clearly documented inheritance where applicable. Your acceptance gate should require traceability and evidence. ¹

What counts as “complete coverage” in practice?

You need a control-to-test mapping that accounts for every required control with either direct test evidence or documented inheritance/exclusion rationale approved by the system owner. Auditors want to see that nothing required is missing from scope. ¹

How do we set the “level of rigor” if the parameter is undefined in our program?

Define a program standard that specifies acceptable test methods and minimum depth for higher-risk controls, then apply it consistently across systems. SA-11(7) assumes you set that expectation and require developers to meet it. ¹

How should we handle third-party software where we can’t see their full test evidence?

Require a coverage attestation plus a mapping to their assurance artifacts (test summaries, certifications, assessment reports) and document what you accept versus what you must test yourself during integration. Record exceptions and compensating controls where transparency is limited.

Is a penetration test enough to satisfy SA-11(7)?

Usually not by itself. A penetration test covers certain technical risks, but SA-11(7) expects testing and evaluation scope to cover all required controls, many of which require configuration inspection, design review, operational tests, or evidence of process controls. ¹

What’s the cleanest audit-ready artifact set?

A Required Controls List, a rigor standard, a Controls Coverage Matrix, linked test plans/results, and a signed scope verification record with documented exceptions. That combination shows both completeness and governance. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5