What it means
A control is a safeguard with a specific job. It may prevent an unwanted action, detect a problem, or help restore service after a failure. Controls can be technical, physical, or procedural: a permission check, a locked equipment room, and an access review each address different conditions.
Describe the intended outcome before selecting a tool. Then identify who operates the control, where it applies, how it can fail, and what evidence shows it works. A policy document states an expectation; implementation and testing establish whether that expectation is met. Several controls may support one risk response, and one control may address several risks.
See the idea / Risk
A safeguard has a trigger, an owner, and a test.
Follow an independent verification rule before one fictional supplier-bank change is permitted or refused.
SupplierDesk R91 asks to change S91 from B17 (ending 4408) to B19 (ending 9931) and suggests untrusted contact C88. Nora’s rule requires a callback through C17 from the previously approved K91 contact book. Contact-book accuracy and callback identity are assumed. Compare C17 denying the request with C17 confirming it. All references are synthetic; no payment occurs.
01 / 04
Define check
R91 names a new bank reference, but the original mandate remains in force. Nora requires independent verification before any change.
More about this step
The approved M91 snapshot says B17, ending 4408. R91 requests B19, ending 9931, and suggests C88. Nora is the authorized operator. This fixture gates the change on a recorded response from approved contact C17; the incoming message cannot supply its own verification.
Step through at your own pace.
Keep in mindThese results test one configured procedure and controlled request. They do not prove that contact identity, every exception path, other transactions, or the whole finance process is secure. A document alone would not enforce the rule; the modeled change gate does.
Read the visual, step by step
C17 denies request
- Define check. R91 names a new bank reference, but the original mandate remains in force. Nora requires independent verification before any change. The approved M91 snapshot says B17, ending 4408. R91 requests B19, ending 9931, and suggests C88. Nora is the authorized operator. This fixture gates the change on a recorded response from approved contact C17; the incoming message cannot supply its own verification.
- Call C17. C17 denies R91 through the independent callback. Nora selects C17 from K91, not C88 supplied in R91. The synthetic response is recorded as V91 and bound to this supplier and requested bank reference. The comparison changes only the known contact’s response. Accuracy of K91 and authenticity of C17 are assumptions, not independently audited claims.
- Enforce rule. The gate refuses the unverified change. The original B17 mandate remains current. The gate checks V91’s supplier, proposed bank, selected known contact and confirmed result. Missing, mismatched or denied evidence cannot authorize the change. It preserves the incoming request and original snapshot. In the confirmed path, permission to change is separate from applying and reading the resulting mandate.
- Read result. Independent readback returns the unchanged B17 mandate. The denied request never changes the supplier’s bank reference. The fixture enforces the same gate at the actual state-changing operation. The confirmed path writes B19 then reads it; the denied path performs no write and reads B17. R91, V91 and original M91 stay retained separately. This exercises both accepted and refused behavior without executing a payment.
C17 confirms request
- Define check. R91 names a new bank reference, but the original mandate remains in force. Nora requires independent verification before any change. The approved M91 snapshot says B17, ending 4408. R91 requests B19, ending 9931, and suggests C88. Nora is the authorized operator. This fixture gates the change on a recorded response from approved contact C17; the incoming message cannot supply its own verification.
- Call C17. C17 confirms R91 through the independent callback. Nora selects C17 from K91, not C88 supplied in R91. The synthetic response is recorded as V91 and bound to this supplier and requested bank reference. The comparison changes only the known contact’s response. Accuracy of K91 and authenticity of C17 are assumptions, not independently audited claims.
- Enforce rule. The gate permits this verified change, while B17 remains current until the change is applied. The gate checks V91’s supplier, proposed bank, selected known contact and confirmed result. Missing, mismatched or denied evidence cannot authorize the change. It preserves the incoming request and original snapshot. In the confirmed path, permission to change is separate from applying and reading the resulting mandate.
- Read result. Nora applies the permitted change. Independent readback returns B19, and the original M91 snapshot remains retained. The fixture enforces the same gate at the actual state-changing operation. The confirmed path writes B19 then reads it; the denied path performs no write and reads B17. R91, V91 and original M91 stay retained separately. This exercises both accepted and refused behavior without executing a payment.
These results test one configured procedure and controlled request. They do not prove that contact identity, every exception path, other transactions, or the whole finance process is secure. A document alone would not enforce the rule; the modeled change gate does.
Flow references: NIST SP 800-53 Rev. 5: functionality and assurance
AN ILLUSTRATIVE SCENARIO
A supplier request and an independent check
SupplierDesk R91 asks Nora to change S91’s bank reference and suggests contact C88. The configured gate instead requires a response from C17 in the approved K91 book. A denial refuses the change and retains B17; a confirmation permits the change, after which independent readback returns B19. The original mandate, request and verification record remain. The fixture tests the procedure under explicit contact-identity assumptions; no payment occurs.
Put it to work
- Name the unwanted event and write the behavior the control must prevent, detect, or help recover from.
- Define its scope, operator, trigger, evidence, and exception process; include dependencies such as accurate contact records or working logs.
- Test the control with a representative safe case and review whether failures reach someone who can correct them.
How to check your work
Trace a recent transaction through the control. You should find the required check, its result, an accountable operator, and evidence that an intentionally invalid test would be caught.
Connect the ideas
- Risk
The potential for harm, assessed using what could happen, how likely it is, its impact, and what remains uncertain.
- Residual risk
The risk that remains after implemented safeguards, including uncertainty in its assessment.
- Defense in depth
Layering independent controls so that one failure does not become a complete compromise.
- Compensating control
An alternative safeguard used in place of a specified control, with evidence that it provides comparable protection for the intended security objective.