What are controls?

In risk and ISO language, a control is something you deliberately rely on to change the likelihood or impact of a risk—policy, process, training, technology, physical measure, or oversight. Controls are how “we should be safer” becomes accountable work with owners and evidence.

Prevent, detect, respond

Teams often group controls by what they do:

• Preventive — stop the event (access rules, secure coding standards, segregation of duties).
• Detective — tell you when something went wrong (logging, IDS, reconciliations, audits).
• Corrective / recovery — limit damage or restore service (backups, incident playbooks, disaster recovery).

Real programmes blend all three; over-indexing on prevention without detection is a common blind spot.

Controls and ISO 27001

ISO/IEC 27002 lists practice-oriented controls; ISO 27001 expects you to select controls as part of risk treatment and document applicability in your Statement of Applicability. The standard cares that choices fit your risks—not that you implement every line item blindly.

Designed vs operating effectiveness

Design asks: if people followed the control as written, would it address the risk? Operating effectiveness asks: does it actually happen in real life? Mature ISMS evidence mixes policy, tickets, test results, metrics, and samples—whatever is reasonable for the control’s importance.

Why the control library matters

When controls live only in slide decks, risks and SoA drift apart from reality. A control register gives each control an identity: purpose, owner, category, status, monitoring cadence, and effectiveness judgement—then risk records can link to the controls that justify residual ratings.

See how ISMSVision models this in managing risks in ISMSVision (detailed), how that maps to ISO clauses in ISMSVision and ISO 27001 risk requirements, and how the same library feeds the Statement of Applicability.