An implementation statement is the paragraph in your system security plan that says how a control is met. For NIST SP 800-53 systems there is one per control, sometimes one per control part, and a Moderate system has a lot of them. They are tedious to write, so they tend to get written badly.
Badly written statements cost more than time. An assessor reads each one as a claim and designs a test to check it. A vague statement produces a vague test, an argument about what you meant, and often a finding. A precise statement tells the assessor exactly what to examine, and the assessment goes faster because there is less to dispute. This article covers what a statement must contain, how to write one that survives testing, and how to handle inherited and partial implementations.
What an assessor does with your statement
NIST SP 800-53A describes three assessment methods: examine, interview, and test. An assessor examines documents and configurations, interviews the people who run the control, and tests mechanisms to see that they behave as described.
Your statement tells the assessor what to examine, whom to interview, and what to test. If it says "account lockout is enforced by the identity provider after the number of attempts set in the access control policy," the assessor knows to read the policy, look at the identity provider's configuration, and attempt failed logons. If it says "the organization enforces account lockout in accordance with policy," the assessor has to work all of that out, and will ask you.
That framing settles most style questions. Write so that someone who has never seen your system could plan the test from your words alone.
What every statement must cover
Use this as a checklist for each control.
- Not done:
Every lettered part. If the control has parts (a) through (d), the statement addresses each, in order, labeled.
- Not done:
Every parameter value. Each organization-defined parameter appears with its assigned value, matching your policy.
- Not done:
Who. The role responsible, not a person's name. Roles survive staff changes.
- Not done:
What. The mechanism: the type of system, the configuration, the procedure.
- Not done:
Where. Which components the control covers, if not all of them.
- Not done:
When. The frequency or trigger, for anything that recurs.
- Not done:
Evidence. What record the control produces, so the assessor knows what to ask for.
- Not done:
Responsibility split. For inherited or hybrid controls, which parts are provided by whom.
If a statement covers all eight, it is usually testable. Most weak statements miss "every lettered part" or "every parameter value."
A weak statement and a stronger one
Take AC-7, Unsuccessful Logon Attempts. Part (a) requires a limit on consecutive invalid logon attempts within a time period. Part (b) requires an automatic action when the limit is exceeded. Both values and the action are organization-defined.
A weak statement:
The organization limits unsuccessful logon attempts in accordance with its access control policy. Accounts are locked when the limit is exceeded.
It restates the control. It gives no values, names no mechanism, and does not say which logons are covered.
A stronger statement, for a hypothetical system whose policy sets a limit of five attempts in 15 minutes:
Part (a). All interactive user logons to the system go through the organization's identity provider. The identity provider enforces a limit of five consecutive invalid logon attempts within a 15-minute period, as set in the Access Control Policy, section 4.2. The platform engineering lead owns the configuration.
Part (b). When the limit is exceeded, the identity provider locks the account for 30 minutes and records a lockout event, which is forwarded to the central log platform. Administrative accounts on infrastructure components that cannot use the identity provider are covered by the compensating control described under AC-7 in the tailoring record.
Evidence. Identity provider lockout configuration export; lockout events in the central log platform.
The second version is longer, and every sentence earns its place. An assessor can read the policy section, compare it with the configuration export, attempt six failed logons, and look for the event. The statement also flags the exception before the assessor finds it, which is always better than the reverse.
Inherited, hybrid, and shared controls
Much of a cloud-hosted system's control set is provided wholly or partly by someone else. The statement has to make the division explicit.
Inherited. Say who provides the control and on what basis, then stop. For physical access to a data center you do not operate, name the provider and the authorization or assessment you rely on. Do not paraphrase the provider's implementation: you cannot vouch for it, and an assessor will not test it through you.
Hybrid. Describe your part fully and reference the provider's part. For encryption at rest, the provider may supply the storage encryption mechanism while you manage the key policy, key access, and the configuration that turns it on. Your statement covers the key policy, the access, and the configuration.
Customer responsibility. If you provide a service to others, some controls are theirs. Say so in the statement and in the customer-facing responsibility matrix, with the same words in both places.
The most common error here is over-inheritance: marking a whole family as inherited when only some parts are. If your accounts, your configuration, or your data are involved, part of the control is yours.
Implementation status, stated honestly
Most templates ask for a status alongside each statement. Common values are implemented, partially implemented, planned, alternative implementation, and not applicable. FedRAMP's system security plan template uses a set close to this.
Choose the status that matches reality on the day you sign the plan.
Partially implemented means some parts are in place. Say which parts are and which are not, and reference the plan of action that covers the gap.
Planned means not yet in place. Describe the planned implementation and give a date. A planned control should have a corresponding plan of action item.
Alternative implementation means a compensating control. Reference the tailoring decision that approved it.
Not applicable needs a verifiable reason, ideally the same one recorded when the baseline was tailored.
Describing a planned control in the present tense is the error that does the most damage. An assessor who tests it and finds nothing has to decide whether the rest of your plan can be trusted.
Writing habits that survive assessment
Present tense, active voice. "The security team reviews firewall rules quarterly" is testable. "Firewall rules should be reviewed" is a wish.
Avoid "may," "should," and "as needed." Each one invites the question of when, exactly.
Do not copy the control text back. If your statement could be pasted under the same control in another company's plan, it says nothing about your system.
Reference, do not duplicate. Point to the policy section or procedure that holds detail, rather than reproducing it. Duplicates drift apart.
Keep values in one place. Parameter values should be stated once in policy and quoted exactly. A statement saying 15 minutes while the policy says 10 is a finding.
Prepare the people named. Interviews test whether the role you named knows the control. Our guide to preparing control owners for interviews covers how.
Statements also age. A configuration change, a new tool, or a reorganization can make a statement false without anyone touching the plan. Tie statement review to change management, so the plan changes when the system does. Our article on the strength of different evidence types explains why system-generated records make the best supporting evidence.
How TrustLynce helps
TrustLynce keeps each implementation statement with its control, owner, parameter values, and the evidence that supports it, so the statement and the proof are reviewed together. Evidence is collected on a schedule from connected systems. See evidence collection, and our NIST 800-53 framework page for how controls are organized.