Designed, implemented, verified: three different claims about a control

A control that has been designed, a control that has been implemented, and a control that is effective are three different claims, and only the third one says anything about risk. A design states the intent and where the control sits in the architecture; an implementation shows the mechanism exists and is configured as specified; effectiveness means the control is implemented correctly, operating as intended and producing the desired outcome. Organisations routinely record the first two and speak as if they had established the third. Keeping them apart is the difference between a plan and an assurance.

The model: design, implementation, operation, verification

design            documented intent: the control, its purpose,
                  and where it sits in the architecture
      ↓
implementation    the mechanism is present and configured
      ↓
operation         the control behaves as specified, over time
      ↓
verification      methods + evidence + depth and coverage
      ↓
                  a claim about effectiveness, re-made as conditions change

The first two stages produce artifacts, the last two a claim that must be maintained. The security plan is the hinge of the design stage: it describes the intended application of each control “with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control” — one sentence serving both implementer and assessor.

What each claim needs

1. Designed. The intent is stated, the control is placed in the architecture, and both are justified. The security plan records the controls planned or in place and the risk determinations behind the design; the security architecture places controls at defined layers so that they operate in a coordinated and mutually reinforcing way. The output is a document, not evidence that anything works.
2. Implemented. The mechanism exists and is configured as the design specifies. Implementation is a fact about the system: a component is present, a setting has a value, a process runs. It is necessary, and it is not the claim that matters most — a control can be implemented exactly as designed and still be the wrong control for the risk.
3. Effective. This is the compound claim: implemented correctly, operating as intended, producing the desired outcome. SP 800-53A defines control effectiveness in those terms; SP 800-137 sharpens it — effectiveness is measured by correctness of implementation and by how adequately the implemented controls meet organisational needs against current risk tolerance. A perfectly implemented control that no longer matches that tolerance is not effective.

Claim	What it asserts	What supports it	Typical artifact
Designed	The intent and the architectural placement are stated and justified	The security plan and the architecture	Plan and design documentation
Implemented	The mechanism exists and is configured as specified	The configured system and the component inventory	The built system
Effective	Implemented correctly, operating as intended, producing the desired outcome	Assessment methods and the evidence they produce	Assessment report

How verification is performed: examine, interview, test

SP 800-53A defines three assessment methods. Examine is reviewing, inspecting, observing or analysing an object to obtain evidence; interview is discussing the control with the people who perform or own it; test is exercising the mechanism to observe its behaviour. They are applied to specifications, mechanisms, activities and individuals.

The assurance obtained is not a matter of applying all three everywhere. Each method carries depth (rigor and level of detail) and coverage (scope or breadth) attributes, valued basic, focused or comprehensive and scaled to the assurance required. SP 800-53A is explicit that “it is not necessary, in most cases, to apply every assessment method to every assessment object to obtain the desired assurance”. A document review with no test establishes design and presence; a test with no document review establishes behaviour, not that it was intended. The combination and the chosen depth and coverage are the assurance case: evidence presented so decision makers can use it.

Continuous monitoring: keeping the claim true over time

Effectiveness is a claim with a date, not a permanent property: a passing assessment certifies a configuration and an environment at a moment, while systems, threats and risk tolerance all move. SP 800-39’s risk monitoring component is directed at exactly this — verify that planned risk responses are implemented, determine their ongoing effectiveness, and identify changes that affect them. SP 800-137 calls the ongoing activity continuous monitoring: maintaining ongoing awareness of information security, vulnerabilities and threats to support risk management decisions. SP 800-53 expresses it at control level as CA-2 and CA-7.

A common misconception: “the control exists, so it works”

The three claims collapse in ordinary speech, and the collapse is where assurance is lost. A control that exists is not a control that works, and a checklist tick is not a proof of effectiveness: a design review establishes intent, not operation; an implemented setting establishes configuration, not behaviour; and a single test result is evidence about the conditions in which it was taken, not a permanent property. Effectiveness asks both whether the control was implemented as planned and whether the plan still meets the organisation’s needs — a control can pass every check while answering a risk the organisation no longer has.

What to remember

• A design states intent and architectural placement; the security plan is its artifact.
• An implementation shows a mechanism exists and is configured; it does not show it works.
• Effectiveness means implemented correctly, operating as intended, producing the desired outcome.
• Verification combines examine, interview and test; depth and coverage fix what the result is worth.
• Effectiveness is dated; continuous monitoring keeps the claim current.

Level and prerequisites

L1 — fundamentals: the three claims a control attracts and what each needs, with no procedure and no tooling. Prerequisites: none, though the treatment-options sheet explains what a risk response is.

Where to go next

• Cybersecurity Governance — the area this sheet belongs to.
• The technical side — how a specific control is configured and operated — belongs to Networking, Server & Virtualization and AI & LLM (roadmap §6).

References

• NIST, Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5) — control effectiveness in CA-2, the security plan (PL-2), security architectures (PL-8 and its defense-in-depth enhancement PL-8(1)), and continuous monitoring (CA-7).
• NIST, Assessing Security and Privacy Controls in Information Systems and Organizations (SP 800-53A Rev. 5) — the definition of control effectiveness, the examine/interview/test methods, depth and coverage, assessment objects, and the assurance case.
• NIST, Managing Information Security Risk: Organization, Mission, and Information System View (SP 800-39) — the risk response and risk monitoring components: verifying that responses are implemented and determining their ongoing effectiveness.
• NIST, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations (SP 800-137) — the ISCM definition and control effectiveness measured by correctness of implementation and adequacy against current risk tolerance.