Term

Control

A safeguard or countermeasure used to reduce risk.

A control is a specific measure implemented to reduce the likelihood or impact of a risk. Controls can be preventive, detective, or corrective, and may be technical, administrative, or physical.

Controls, explained

Every compliance framework, from ISO 27001 to PCI DSS, is ultimately a collection of controls. Yet the word gets used loosely: sometimes for a requirement in a standard, sometimes for a tool, sometimes for a policy sentence. In practice, a control is the specific thing your organization does, repeatedly, to reduce a specific risk. The requirement is what a framework asks for; the control is your answer to it.

Two ways to classify a control

Controls are usually described along two axes: what they do (their function) and how they are delivered (their nature). The grid below gives one real example for each combination. A mature program has a mix, because preventive controls eventually fail and something needs to notice.

Preventive, Detective, Corrective comparison
Aspect	Preventive	Detective	Corrective
Technical	Multi-factor authentication on all remote access	Alerting on impossible-travel sign-ins	Automated rollback of an unauthorized configuration change
Administrative	Background checks before hiring	Quarterly user access review	Incident response plan invoked after a breach
Physical	Badge-controlled server room	CCTV at data center entrances	Replacing a compromised lock and reissuing keys

Anatomy of a well-written control

Objective: the risk it addresses, in one line.
Activity: what is done, specific enough that two people would do it the same way.
Owner: a named role accountable for it running.
Frequency or trigger: continuous, daily, quarterly, or on an event such as a new hire.
Evidence: the artefact that proves it ran, such as a ticket, export, or log.
Mappings: the framework requirements it satisfies.

Design versus operating effectiveness

Auditors test controls in two ways. Design effectiveness asks whether the control, as described, would address the risk if performed. Operating effectiveness asks whether it actually ran as described over a period. A control can be well designed and still fail in operation, for example a quarterly review that was skipped in one quarter. This is the core difference between a SOC 2 Type I and Type II report, and it is why evidence collected over time matters.

Where controls go wrong

Copying the framework wording as the control text, so nobody knows what to actually do.
Writing controls the team cannot sustain, such as daily manual log review with no one assigned.
Defining the same activity separately for each framework, which multiplies evidence requests.
No link back to a risk, so controls pile up without anyone knowing which ones matter most.

One control, many frameworks

The access review above satisfies requirements in ISO 27001 Annex A, the SOC 2 Common Criteria, PCI DSS, and HIPAA at once. Writing it once and mapping it to each framework is the principle behind a unified control library. One control, four frameworks shows the mapping in detail, and the Governance product is where Asurvo keeps the control library and its mappings. For how controls arise from risk decisions, see the risk register entry.

FAQ

Frequently asked questions

What is a compensating control?

A compensating control is an alternative measure used when the expected control is not feasible, providing a similar level of protection. For example, if a legacy system cannot support multi-factor authentication, you might restrict it to a segmented network reachable only through a hardened jump host with MFA. Frameworks such as PCI DSS set specific conditions for accepting them.

What is the difference between a control and a policy?

A policy states intent and rules, such as all remote access must use multi-factor authentication. A control is the mechanism or activity that makes the rule real and checkable, such as the identity provider setting that enforces MFA and the monthly report confirming no exceptions. Policies are often controls themselves, but they rarely stand alone.

Are automated controls better than manual ones?

Automated controls run consistently and generate evidence without effort, so they are generally more reliable. Manual controls remain necessary where judgment is involved, such as deciding whether access is appropriate. A practical approach is to automate the execution or the evidence collection where possible and keep human review for the decisions.

How many controls does a typical program have?

It varies widely with scope, size, and the number of frameworks. What matters more than the count is that each control is owned, tested, and linked to a real risk. A smaller set of well-mapped controls that satisfy several frameworks is usually easier to operate than a large list duplicated per framework.

Keep exploring