Controls: what are they and how do you use them?

What is a control?

A control is a concrete measure you take to manage a risk, meet a standard requirement or demonstrate compliance. It's not about abstract intentions, but it's about things your organisation actually does or has put in place.

Examples of ISO 27001 controls:

• "Access logs are reviewed weekly by the system administrator"
• "All data at rest is encrypted with AES-256"
• "New employees complete security awareness training within 30 days of joining"

Every control is demonstrable. That's what distinguishes controls from good intentions. An auditor doesn't want to hear that you "pay attention to access management". They want to see the logs, read the policy, review the training records.

Controls sit at the implementation layer beneath a framework requirement. The framework tells you what you need to do. The control is the concrete answer to how you do that in your organisation.

Technical, organisational and physical controls

Controls are categorised by type:

Technical controls are built into systems and infrastructure. Think firewalls, encryption, multi-factor authentication (MFA), access management, logging and patching. They can largely run automatically once configured and maintained in Tidal.

Organisational controls are about how people work. Policies and procedures, job descriptions, security awareness training, employee background checks. They require conscious compliance and regular review.

Physical controls protect the physical environment. Access badges for server rooms, camera surveillance, a clean desk policy, secure hardware disposal. Less visible in digital compliance programmes, but certainly relevant for ISO 27001.

Preventive, detective and corrective

Beyond type, you can also categorise controls by function:

Preventive controls stop something from going wrong. MFA prevents unauthorised access. A password policy prevents weak credentials. A clean desk policy prevents information leaks through documents left lying around.

Detective controls signal when something is going wrong or has already gone wrong. Login monitoring, audit logs, intrusion detection systems. They don't stop the incident, but they make sure you spot it quickly enough.

Corrective controls help you recover after an incident. An incident response process, a backup strategy, a recovery plan. Well-designed corrective controls determine how quickly you're back up and running after a disruption.

A mature security programme has all three. Thinking only in terms of prevention is dangerous, because it assumes nothing will ever get through. Detection and response are your safety net.

How controls work within a framework

Frameworks specify which topics you need to cover. Controls are your concrete answer to those requirements.

ISO 27001 is the most commonly used example here. Annex A of the standard contains 93 controls, divided across 4 domains: organisational controls, people controls, physical controls and technological controls. You're not required to implement all 93. You carry out a risk assessment and use that to select which controls are relevant for your organisation, your environment and your risks.

Every control you don't apply needs to be justified. That's what the Statement of Applicability (SoA) is for. The SoA is a central document that tracks, for each control, whether it applies, whether it has been implemented in the organisation and why certain controls have been excluded. An auditor starts here.

One risk often calls for multiple controls at once. The risk of "unauthorised access to customer data" isn't addressed by MFA alone. You combine that with an access management policy, log reviews and incident response. And conversely, one control can address multiple risks at the same time. That makes for more efficient working and management, especially when you're managing multiple frameworks through a single GRC approach.

What makes a good control

Not every control that exists on paper works in practice. A good control meets four criteria:

Specific. "We pay attention to security" is not a control. "Privileged accounts are reviewed monthly by the CISO" is. The more specific the description, the easier it is to implement and test.

Ownership. Every control has an owner, someone responsible for its execution and for collecting evidence. A control without an owner drifts. It doesn't get updated, executed or evidenced.

Demonstrable. You don't just record that a control is "in place". You build up evidence: logs, review reports, configuration screenshots. An auditor doesn't just ask whether you have the control, they ask for proof that it actually works.

Proportionate. The control must fit the risk and the maturity of your organisation. A small organisation implementing all 93 Annex A controls without prioritisation is making things unnecessarily hard for itself. Start with the controls that address the biggest risks.

Common mistakes with controls

In practice, organisations tend to go wrong in the same ways.

Choosing controls without a risk assessment. Controls are not a random best-practice checklist. They are your response to identified risks. Starting to fill in Annex A without first knowing what your risks are means working backwards.

Paper controls. A control that exists on paper but doesn't work in practice, the so-called "paper reality" is one of the fastest ways to fail an audit. Auditors spot them immediately. They don't just ask for the policy document; they also ask for evidence that it has been accepted and is being followed.

No ownership. "We have an access management policy" sounds good. But who is responsible? Who makes sure it's reviewed annually? Who collects the evidence that it's still in good shape? If the answers to those questions are unclear, the control exists only on paper or in the security officer's head.

Too many controls for the organisation's maturity. Thirty controls that genuinely work beats 93 that are half-implemented. An audit finding on a control that isn't fully in place is a non-conformity. Prioritise by risk, build step by step and expand only once the basics are solid.

Managing controls in practice

Managing one control is straightforward. Ten controls are still manageable. But once you're getting towards twenty, thirty or more with owners spread across teams, multiple frameworks and periodic review obligations, a spreadsheet often loses its grip.

In practice, good controls management means:

• Recording and making ownership visible per control
• Collecting evidence continuously, not just in the run-up to an audit
• Tracking review dates so you know when something was last assessed
• Linking controls to the frameworks and risks they cover

Tidal Control's platform is the place that centralises exactly this. Per framework, per domain, with assigned owners and attached evidence. That turns control review into an ongoing process rather than a two-week sprint before your certification audit.

Frequently asked questions about controls

What is the difference between a control and a policy rule?

A policy rule describes what your organisation wants or requires. A control is the concrete action or configuration that fulfils that requirement. The policy says: "Access to systems is restricted based on the need-to-know principle." The control is: "Access rights are reviewed quarterly by the system owner and documented in the ITSM system." Policy is the intention; the control is the execution.

Do I have to implement all 93 Annex A controls from ISO 27001?

No. ISO 27001 requires you to carry out a risk assessment and select controls based on that. Controls you don't apply don't need to be implemented. However, you do need to document why they are not applicable. You do that in the Statement of Applicability.

How do I demonstrate that a control works?

By collecting and maintaining evidence. Depending on the control, that might be a log file, a training record, a review report, a configuration screenshot or a signed document. The evidence shows that the control doesn't just exist on paper but also works in practice.

How often do I need to review controls?

This varies by control and by framework, but as a rule of thumb: at least annually, and immediately after a significant change in systems, processes or risks. ISO 27001 requires that the ISMS, including its controls, is independently reviewed on a periodic basis.

What is the difference between a control and a risk control?

In practice, the terms are used interchangeably. Technically, a risk control is the broader category: any measure that influences a risk. A control is the concrete implementation. Most ISO 27001 implementations use "control" as the standard term for what the standard itself calls a "control".

Not sure where to start?

Take the free Quickscan → and discover in five minutes where your organisation stands and what you can tackle first.