cx-control-testinglisted

# Testing a support control A control is a thing that is supposed to prevent or detect a specific failure — a four-eyes check on a refund above a threshold, a mandatory disclosure on a call, a complaint identification step, an approval gate before an account is closed. Most internal control review asks "is there a control?" and "is it documented?". An auditor asks a harder question: **does it operate, on every occasion, and would it catch the failure it exists for?** The gap between those is where findings live. ## Design effectiveness and operating effectiveness Two separate tests. Both are needed and they fail differently. **Design** — if the control operated perfectly every time, would it prevent or detect the failure? Common design defects: - **It detects too late** to prevent harm. A monthly review of daily decisions is a reporting activity, not a preventive control. - **It is not linked to the risk.** A control that checks a form was completed, where the risk is that the form was completed wrongly. - **It relies on the same person** who performs the action. Self-review is not a control. - **It has no defined response.** A detection with no required action detects and does nothing, and this is extremely common. - **It is bypassable** by design — an optional field, a skippable step, a warning with a continue button. **Operating** — does it happen, every time, as designed? Test this on evidence, not on assertion. A control can be well designed and never ope