October 05, 2026
How Do I Write a Good Requirement Response?
What is a requirement response?
Your System Security Plan (SSP) must cover all 110 NIST SP 800-171 requirements.
Each requirement needs a short written answer called a requirement response.
It tells the assessor exactly how your company meets that requirement.
It also points to the proof: policies, logs, screenshots, and records.
The systems in scope are the ones that store CUI (Controlled Unclassified Information).
Why does the wording matter?
NIST requirement 3.12.4 says your SSP must describe how security requirements are implemented.
NIST SP 800-171A gives assessors three methods: examine, interview, and test.
Your response is what they examine first.
A clear response tells them where to look and who to ask.
A vague response sends them hunting, and hunting slows everything down.
What is the formula?
Use four parts for every response.
What: state what happens in plain words.
How: describe the step or rule that makes it happen.
Who: name the role or person responsible.
Proof: list the evidence that shows it is true.
Miss one part, and the assessor will ask for it anyway.
Write the answer before you collect the evidence.
Example: a good response
Requirement 3.1.1 says to limit system access to authorized users.
Good response:
What: Only approved employees can log in to company systems.
HR approves each new hire before IT creates the account.
The IT administrator creates the account within one business day.
The IT administrator removes accounts within one business day after separation.
Proof: new hire approval emails, the current user account list, and the termination log.
That response works because each 800-171A check has a matching answer.
An assessor can examine the account list, interview the IT administrator, and test the account process.
Example: a bad response
Bad response:
We have strong access controls in place for all users.
Our IT team manages this.
This fails on all four parts.
What is not described.
How is missing.
Who is just "IT team" with no role named.
Proof is not mentioned at all.
An assessor cannot examine, interview, or test a sentence like this.
It will come back with questions every time.
Example: a requirement that does not apply
Requirement 3.1.13 covers control and monitoring of remote access sessions.
If your company truly has no remote access, say so plainly.
Good not-applicable response:
What: No system that stores CUI allows remote access.
Our firewall blocks all inbound remote connections.
Who: The network administrator owns this rule.
Proof: the firewall policy and the blocked connection log.
A not-applicable answer still needs all four parts.
"Not applicable" is not a reason by itself.
Explain what is missing and show the proof.
Assessors accept not-applicable answers when the facts back them up.
What mistakes slow assessors down?
Vague words: "appropriate," "adequate," and "proper" say nothing.
One-line answers: if it fits in one short line, it is missing parts.
Policies that do not match practice: the written rule must match what people do.
Evidence on the wrong requirement: a password policy does not prove access control logging.
No person named: "handled by IT" is not a name or a role.
No date: evidence without a date cannot prove a current process.
Hiding gaps: if a requirement is not met yet, say so.
Point to the POA&M (Plan of Action and Milestones) entry instead.
NIST requirement 3.12.2 expects a plan of action for each unmet requirement.
Assessors trust honest gaps more than hidden ones.
How do you keep 110 responses consistent?
Write all responses from the same formula.
Use one evidence folder per requirement.
Name files so the assessor can find them without asking.
Review each response against the 800-171A procedure for that requirement.
The procedure lists exactly what the assessor will examine, interview, and test.
If your response answers those checks, you are ready.
What about the revision?
These examples use NIST SP 800-171 Rev 2.
NIST withdrew Rev 2 in May 2024 and replaced it with Rev 3.
The formula in this article works for either revision.
Gathering the proof takes the longest time
Most teams finish the writing fast. They then spend weeks chasing screenshots and logs.
Software can do that gathering for you.
PolicyCortex reads live Azure configuration with 33 collectors.
It builds SSP, SAR (Security Assessment Report), and POA&M output from the collected evidence.
See policycortex.com.