3.3 Security Control Selection
3.3 Security Control Selection
Security controls should be selected because they satisfy identified security requirements and reduce relevant risk - not simply because a technology is popular or available.
Good control selection starts with understanding the system, the information it processes, the threats it faces and the consequences if confidentiality, integrity or availability are compromised.
Requirements
Understand what the system must protect and why.
WHAT IS REQUIRED?Controls
Select safeguards that address the identified requirements and risk.
WHAT WILL PROTECT IT?Validation
Confirm that the controls are implemented and operating effectively.
DOES IT ACTUALLY WORK?The Big Idea
Control selection should follow the security requirement.
It should not begin with the security product.
Control Selection Flow
Requirement → Control → Assessment
Security Requirements Come First
Before choosing controls, the organisation must understand what security outcomes are required.
What does the business need the system to do safely?
Which confidentiality, integrity and availability protections are required?
Which laws and regulatory obligations apply?
What security obligations have been agreed with customers, suppliers or partners?
Which identified risks require treatment?
What protection is required for personal information?
What availability, performance and resilience requirements must be preserved?
Which frameworks, standards or sector-specific expectations apply?
A hospital is designing a new clinical system.
The architect should not begin by asking:
"Which firewall should we buy?"
The architect should first understand requirements such as:
- patient information must remain confidential;
- medical records must maintain integrity;
- clinical staff require rapid availability;
- access must be attributable to individual users;
- relevant privacy and healthcare requirements must be met;
- critical services must remain resilient.
Appropriate controls can then be selected against those requirements.
What is a Security Control?
A security control is a safeguard or countermeasure intended to reduce risk or help achieve a security objective.
Controls can involve:
MFA is a control.
A background-check process is a control.
A locked data-centre door is a control.
Separation of duties is a control.
A documented approval process is also a control.
🧱 Control Categories Administrative, technical and physical controls
One useful way to classify security controls is by how they are implemented.
Administrative
Policies, governance, processes and human activities.
PEOPLE & PROCESSTechnical
Technology that enforces or supports security.
TECHNOLOGYPhysical
Physical mechanisms protecting people, facilities and equipment.
PHYSICAL WORLDAdministrative Controls
Administrative controls establish direction, responsibilities and processes.
Technical Controls
Technical controls use hardware or software to enforce or support security requirements.
Physical Controls
Physical controls protect facilities, equipment and people.
A strong design may combine:
Administrative: authorised-access policy.
Technical: electronic access-control system.
Physical: reinforced door and security camera.
A technical control rarely exists entirely independently of administrative processes and physical realities.
⚙️ Control Functions What is the control trying to do?
Controls can also be classified according to the security function they perform.
| Function | Purpose | Example |
|---|---|---|
| Directive | Tells people what must or should be done. | Security policy |
| Deterrent | Discourages an unwanted action. | Warning sign or visible CCTV |
| Preventive | Attempts to stop an unwanted event. | Firewall rule or MFA |
| Detective | Identifies that an event has occurred or is occurring. | IDS or security monitoring |
| Corrective | Corrects or limits the consequences of a problem. | Reimaging a compromised endpoint |
| Recovery | Restores capability following disruption. | Restoring from backup |
| Compensating | Provides an alternative means of addressing a security requirement when the preferred control cannot be used. | Additional segmentation around an unsupported legacy system |
One Risk - Multiple Control Functions
Consider the risk of an attacker obtaining unauthorised access to a sensitive system.
Prevention is valuable, but good security architecture assumes that preventive controls may eventually fail.
Detection, response and recovery therefore matter too.
Category vs Function
A common CISSP mistake is treating these as the same classification.
HOW or through what mechanism is the control implemented?
WHAT is the control trying to accomplish?
CCTV may be considered a:
Physical control because of how it is implemented.
It may act as a:
Detective control because it records activity.
Visible CCTV may additionally provide a:
Deterrent effect.
Category vs Function
Category = HOW · Function = WHAT
🛑 Preventive Controls Stop the event before it happens
Preventive controls are intended to stop or reduce the likelihood of an unwanted event.
Makes account compromise using only a stolen password more difficult.
Blocks traffic that is not permitted by policy.
Restricts what a user or process can do.
Prevents inappropriate input from reaching sensitive application functions.
Restrict physical access.
Restricts unnecessary communication between security zones.
Preventive controls reduce risk but should not be assumed to stop every attack.
🔎 Detective Controls Identify activity that has happened or is happening
Detective controls provide visibility when prevention fails or suspicious behaviour occurs.
MFA is bypassed through session-token theft.
A behavioural monitoring system detects:
- an unusual source location;
- abnormal transaction volume;
- access to resources the user rarely uses.
The preventive control was bypassed, but the detective layer can still identify suspicious behaviour.
🛠️ Corrective & Recovery Controls Respond after something goes wrong
Attempts to correct the problem or limit its consequences.
Restores systems, services or information following disruption.
Corrective controls address the cause or immediate consequence of a problem.
Recovery controls restore required capability.
🔄 Compensating Controls An alternative when the preferred control cannot be implemented
Sometimes the preferred security control cannot be implemented because of:
A critical industrial system cannot support modern MFA.
Immediate replacement is not possible.
The organisation might introduce:
- network isolation;
- restricted administrative jump hosts;
- strong authentication before reaching the management network;
- enhanced monitoring;
- strict physical access;
- additional administrative approval.
These measures may compensate for part of the missing capability.
The organisation should still understand the remaining residual risk.
Compensating Control
Different control · Same security objective
📏 Security Control Baselines A starting point for selecting controls
Organisations do not necessarily need to design every control set from zero.
A control baseline provides an initial set of controls that can then be adapted to the system and its risk.
The organisation still needs to consider the actual system, technology, threats, operating environment, business requirements and risk.
Scoping and Tailoring
These concepts appeared in Asset Security and are also important when selecting architecture controls.
Determine where the control or requirement applies.
Think: WHERE?
Adapt the baseline or control implementation to the particular system, environment and risk.
Think: HOW?
A security standard requires MFA for privileged administrative access.
Scoping:
Which systems, accounts and administrative interfaces are considered privileged?
Tailoring:
Which approved authentication technologies and implementation methods are appropriate for those systems?
Scoping vs Tailoring
Scope = WHERE · Tailor = HOW
Factors That Influence Control Selection
The same control set is not automatically appropriate for every system.
Asset Value
How important are the information and systems being protected?
Classification
How sensitive or critical is the information?
Threats
Which threat actors and attack paths are relevant?
Vulnerabilities
Which weaknesses increase exposure?
Impact
What happens if confidentiality, integrity or availability fails?
Legal Requirements
What is mandatory?
Technology
Which controls are technically possible and appropriate?
Operational Needs
Could the control interfere with safety, availability or business processes?
Cost
Is the control economically reasonable relative to the risk?
Existing Controls
Which protections are already in place?
Architecture
Where can the control most effectively be applied?
Residual Risk
What risk remains after the control is implemented?
💰 Cost vs Risk Reduction More security is not automatically better security
Security controls consume resources.
They can introduce:
An organisation wants to protect a publicly available cafeteria menu from unauthorised disclosure.
Implementing a £5 million classified-network architecture would not be a proportionate control.
The information has little confidentiality requirement.
Security architecture attempts to achieve appropriate protection, not maximum possible protection regardless of cost or operational impact.
💪 Control Strength & Assurance Having a control is not enough
Two systems may both claim to use the same control while receiving very different levels of protection.
System A:
MFA is enabled only for administrators when they log in from outside the office.
System B:
phishing-resistant MFA is required for all privileged access, regardless of network location.
Both can claim to use: MFA.
Their control strength and implementation are clearly different.
Also ask:
"Is it designed, implemented and operating strongly enough for the requirement?"
🏢 Common, System-Specific & Hybrid Controls Who provides the protection?
A control provided centrally and inherited by multiple systems.
Example: organisational physical security for a shared data centre.
A control implemented specifically for an individual system.
Example: application-specific transaction validation.
A control with both shared and system-specific elements.
Example: central identity infrastructure combined with application-specific authorisation rules.
The organisation provides a central identity platform.
The platform authenticates employees.
A banking application then decides which accounts each authenticated employee can access.
Part of the identity control is shared centrally, while part is specific to the application.
Control Selection and Defence in Depth
Control selection should consider what happens if one safeguard fails.
Defence in depth is about complementary layers rather than simply buying several products that perform exactly the same function and fail in the same way.
Selecting Controls for an Online Banking Service
An organisation is designing a new internet-facing banking service.
The architecture team identifies several security requirements.
| Requirement | Possible Control | Function |
|---|---|---|
| Prevent simple password theft from immediately compromising accounts. | MFA | Preventive |
| Protect customer information sent across public networks. | TLS | Preventive |
| Detect unusual account access. | Security monitoring and behavioural analytics | Detective |
| Limit the damage if an application service is compromised. | Least privilege and segmentation | Preventive / Limiting |
| Restore customer information after destructive failure. | Protected backups | Recovery |
| Ensure sensitive production changes are appropriately approved. | Change control and segregation of duties | Administrative / Preventive |
The architecture did not start with: "We want MFA."
It started with: "We need to reduce the risk of account takeover."
MFA was then selected as one control contributing to that requirement.
💥 Controls Can Introduce Risk A security control becomes part of the architecture
Adding a control can introduce new dependencies and failure modes.
What happens if the control becomes unavailable?
Does inspection create unacceptable latency?
Could compromising the control provide powerful access?
Does the control collect sensitive monitoring information?
Can administrators realistically operate it correctly?
Does the control create a new single point of failure?
Every employee must authenticate through one central identity service.
This improves consistency and security.
However, the identity service now becomes:
- a critical availability dependency;
- a highly attractive attack target;
- a potential organisation-wide single point of failure.
The architecture should therefore protect and make that control resilient.
Selection is Not the End
Choosing an appropriate control does not mean the requirement has been satisfied.
🎓 CISSP Scenarios Choose the control based on the requirement
A company wants to prevent employees from entering a restricted server room without authorisation.
What type of control would an electronic door lock primarily be?
Physical / Preventive.
Security staff review logs to identify suspicious administrator activity.
What function does this control perform?
Detective.
An unsupported production system cannot support MFA and cannot yet be replaced.
The organisation isolates it behind an administrative jump host, restricts network access and introduces additional monitoring.
What are these controls?
Compensating controls.
After ransomware destroys production information, data is restored from protected backups.
What control function is demonstrated?
Recovery.
A security policy states that employees must use company-approved systems when processing customer information.
What control function is the policy providing?
Directive.
A visible security camera discourages employees from attempting to enter a restricted area.
Which functions may it provide?
Deterrent and Detective.
A system is classified as highly critical. The architect immediately purchases the most expensive firewall available without first identifying security requirements.
What is wrong with this approach?
Control selection should be driven by system security requirements and risk, not product selection first.
A company adopts a standard security baseline and then determines which controls apply to its cloud environment and adjusts implementations accordingly.
What process is occurring?
Scoping and tailoring.
The organisation uses one centrally managed physical-security system for hundreds of applications hosted in its data centre.
What type of control is this?
Common control.
A central identity provider authenticates employees, while each application independently determines its own authorisation rules.
How could the overall control be described?
Hybrid - part shared centrally and part system-specific.
An architect chooses multiple controls that all rely on the same identity provider.
What should also be considered?
The identity provider may become a common dependency and potential single point of failure.
A control was successfully implemented two years ago, but nobody has checked whether it still works.
What is missing?
Ongoing assessment and monitoring of control effectiveness.
How to Approach Control Selection Questions
CISSP questions often include several technically possible controls.
The correct answer is usually the control that best satisfies the actual requirement and risk described in the scenario.
Do not immediately select technology simply because the question contains a technical problem.
Determine the requirement first.
⚠️ Common CISSP Mistakes Avoid selecting controls for the wrong reason
Do not begin with: "Which product do we want?"
Begin with: "What security requirement must be satisfied?"
Technical describes the type of control.
Preventive describes what it does.
Preventive controls reduce likelihood but can still fail or be bypassed.
A compensating control should address the underlying security objective through an alternative mechanism.
Excessive controls can increase complexity, cost and dependencies.
A baseline is a starting point that should be adapted to the actual system and risk.
Implementation and ongoing effectiveness must be assessed.
Residual risk normally remains after controls are implemented.
Quick Reference
| If you need to... | Think... |
|---|---|
| Tell users what is required | Directive |
| Discourage unwanted behaviour | Deterrent |
| Stop an event | Preventive |
| Identify an event | Detective |
| Correct a problem | Corrective |
| Restore capability | Recovery |
| Use an alternative where the preferred control is impossible | Compensating |
| Start from a predefined control set | Baseline |
| Determine where controls apply | Scoping |
| Adapt controls to a specific environment | Tailoring |
| Provide one control centrally to many systems | Common Control |
| Protect one particular system | System-Specific Control |
Control Function Memory Aid
Direct → Deter → Prevent → Detect → Correct → Recover
The Architect's Control Selection Questions
Controls follow requirements - requirements do not follow controls.
Key Takeaways
Security controls should be selected based on system security requirements and risk.
Start with the requirement, not the security product.
Security requirements may originate from business needs, risk assessments, laws, regulations, contracts, privacy obligations and industry standards.
Controls can be administrative, technical or physical.
Control category describes the nature of the control while control function describes what the control is intended to accomplish.
Preventive controls attempt to stop unwanted events.
Detective controls identify events that occur.
Corrective controls address problems after they occur.
Recovery controls restore required capability following disruption.
Directive controls establish expected behaviour while deterrent controls discourage unwanted behaviour.
Compensating controls provide an alternative way of addressing a security objective when the preferred control cannot be implemented.
Control baselines provide a useful starting point for control selection but should be adapted to the actual system and environment.
Scoping asks WHERE controls apply. Tailoring asks HOW they should apply.
Controls can be common, system-specific or hybrid depending on where responsibility and implementation reside.
Control selection should consider cost, operational impact, asset criticality, threats, vulnerabilities and residual risk.
Controls can introduce their own dependencies and failure modes, so their architecture must also be considered.
Selecting a control is not enough. The organisation must confirm that it has been implemented correctly and continues to operate effectively.
📚 Sources & Further Reading Control selection and security architecture guidance
- ISC2 - CISSP Certification Exam Outline
View the CISSP Exam Outline - NIST SP 800-53 Rev. 5 - Security and Privacy Controls for Information Systems and Organizations
View the NIST control catalog - NIST SP 800-53B - Control Baselines for Information Systems and Organizations
View NIST control baselines and tailoring guidance - NIST Risk Management Framework - Select Step
View NIST control-selection guidance