Control Selection and Security Frameworks - Building Your Control Library

Article 3 of 7 in the System Security Concepts series

Introduction: the control selection challenge

Most organisations fail at control selection because they approach it backwards, starting with technical controls and hoping they protect something valuable. This is security theatre, not security.

Military forces don’t defend weather stations like nuclear facilities. Different threats, different assets, different response. A weather station might have a fence and basic access control. A nuclear facility has multiple security zones, armed guards, biometric access, continuous monitoring, and rapid response teams. The difference isn’t arbitrary, it maps directly to threat capability and asset criticality.

This is proportionate response: matching defensive intensity to the combination of threat level and asset value.

Security control selection works the same way:

Business Need (CIA+) → Threat Assessment → Risk Level → Proportionate Control Response

Confidentiality need → Data exfiltration threats → High risk → Strong access controls + DLP + encryption
Integrity need → Data tampering threats → Critical risk → Digital signatures + change auditing + segregation
Availability need → Denial of service threats → Medium risk → Redundancy + monitoring + incident response

Control selection begins with three questions:

What security properties does the business require?

Security properties translate business language into technical language:

Confidentiality: Would unauthorised data disclosure harm the business? (Customer data breach, intellectual property theft, regulatory violation)
Integrity: Would unauthorised data modification harm the business? (Financial records tampering, safety-critical data corruption, supply chain data manipulation)
Availability: Would system downtime harm the business? (Production line stoppage, customer-facing service outage, transaction processing failure)
Non-repudiation: Would disputed transactions harm the business? (Payment disputes, contract denial, audit trail gaps)
Authenticity: Would impersonation harm the business? (Fraudulent transactions, unauthorised system access, spoofed communications)
Accountability: Would attribution failures harm the business? (Insider threat detection, forensic investigation, compliance reporting)

What level of protection is proportionate?

Five factors determine proportionate protection:

System criticality to business operations (production-critical vs. back-office)
Data sensitivity and classification (public vs. confidential vs. restricted)
Regulatory and contractual obligations (NIS2, GDPR, PCI DSS requirements)
Threat actor capability and motivation (opportunistic vs. targeted attacks)
Risk appetite and tolerance thresholds (defined by organisational risk management)

What control intensity matches the risk?

Three-tier model maps risk to control intensity:

Baseline controls: Mandatory for all systems (low/moderate risk)
Enhanced controls: Required for elevated-risk systems
Advanced controls: Critical/high-risk systems only

Ad-hoc control selection creates three problems:

Misalignment: technical controls selected without connection to business risk. Security teams implement firewalls, encryption, and monitoring but can’t articulate which business harm these prevent. During audits or incidents, this disconnect becomes expensive.
Inconsistency: similar systems receive different protection levels based on architect preference, not risk. Payment processing gets basic controls while the HR system gets advanced controls, despite inverse risk profiles. Attackers exploit the weakest link; inconsistency creates weak links.
Resource waste: low-risk systems get over-engineered. Critical systems get under-protected. Resources flow to whoever shouts loudest, not actual risk. Finance gets frustrated paying for controls they don’t understand. The CISO can’t demonstrate ROI.

Framework-based control selection solves these problems.

Security frameworks (ISO 27001/27002, NIST CSF/800-53, IEC 62443, CIS Controls) provide:

Structured approach: maps business needs to security properties to threats to controls with documented rationale. Every control selection can be explained to auditors, executives, and architects.
Risk-based tiering: pre-defined control sets for baseline, enhanced, and advanced protection levels. Systems inherit controls based on criticality assessment, not architect opinion.
Industry validation: controls proven across thousands of organisations. Don’t reinvent authentication, access control, or monitoring patterns.
Compliance evidence: frameworks map to regulations (NIS2, GDPR, PCI DSS). Single control implementation satisfies multiple regulatory requirements.
Proportionate response model: control intensity scales with risk automatically. High-risk systems get advanced controls; low-risk systems get baseline protection.

Rather than selecting controls from scratch for every system, build an organisational control library:

Control catalog: pre-defined controls mapped to frameworks (ISO 27001, NIST 800-53, IEC 62443, CIS Controls). Each control documented once with implementation guidance, evidence requirements, and framework mappings.
Risk-based tiers: controls organised by intensity (baseline/enhanced/advanced). System criticality assessment determines which tier applies.
Inheritance model: systems inherit controls from library based on tier assignment. System security concepts document implementation specifics, not control selection rationale.

Outcome: consistency across systems, efficiency in documentation, proportionate response to risk.

These organisational control libraries draw from established security frameworks. Understanding which frameworks apply, and at what level, determines how you build your library.

Major security control frameworks

Framework	Type	Best For	Certification	Primary Strength
ISO 27001:2022	Organisational ISMS standard	ISMS governance, certification, risk management	Yes (organisational audit)	Global recognition, management system approach
ISO 27002:2022	Implementation guidance (code of practice)	System-level control implementation	No (guidance only)	Detailed ‘how to’ for each control, 5 attributes per control
NIST CSF 2.0	Voluntary framework	Risk management, executive communication	No	Function-based organisation, risk focus
NIST 800-53	Control catalog	US government, regulated industries	No	Comprehensive controls, maturity guidance
IEC 62443	OT/ICS standard series	Industrial control systems, manufacturing	Yes (for systems/products)	Zone & conduit model, OT-specific
CIS Controls	Prioritised control set	Implementation prioritisation, resource-constrained	No	Prioritisation (IG1/IG2/IG3), actionability

ISO 27001 builds organisational governance. ISO 27002 secures individual systems.

Confuse them and you’ll reference the wrong standard in security concepts, fail audits, and frustrate stakeholders who can’t understand why ‘we’re ISO 27001 certified’ doesn’t mean systems are secure.

ISO 27001:2022 (Organisational ISMS Framework):

Certifiable standard for organisational information security management
Contains Annex A with 93 control objectives (high-level ‘what’ to implement)
Defines risk management methodology, governance structure, management responsibility
Applied at organisational level, auditors certify your ISMS
Third-party audit results in ISO 27001 certification

ISO 27002:2022 (System-Level Implementation Guide):

Code of practice with detailed ‘how to’ for each Annex A control
NOT certifiable, this is implementation guidance, not a standard
Provides 5 attributes per control (type, security properties, concepts, capabilities, domains)
Applied at system level, security concepts reference this for control implementation
No certification exists for ISO 27002

In system security concepts, reference ISO 27001 Annex A control IDs (e.g., A.5.15, A.5.16) and implement per ISO 27002 detailed guidance. Never state ‘system implements ISO 27001’, systems implement Annex A controls using 27002 guidance.

Different frameworks apply at different levels:

Framework	Organisational level	System level	Notes
ISO 27001	Yes, primary	No (Annex A only)	ISMS at org level; Annex A controls selected per system
ISO 27002	No	Yes, primary	Implementation guidance for system-level controls
NIST CSF 2.0	Yes, primary	Rarely	Enterprise risk framework; systems reference outcomes but not primary level
NIST 800-53	Partial, baseline selection	Yes, primary	Org selects baseline (Low/Moderate/High); systems inherit and tailor
IEC 62443-2-1	Yes, primary (Asset Owner)	No	Organisational IACS security program requirements
IEC 62443-3-3	No	Yes, primary (System)	System security requirements and security levels
CIS Controls	Partial, organisational IG	Yes, per-system IG	Org establishes IG baseline; systems may require higher IG

Common mistakes:

Wrong: ‘We implement NIST CSF at system level’, CSF is an enterprise risk framework
Right: ‘System implements NIST 800-53 controls that support NIST CSF Protect function’
Wrong: ‘Our system is ISO 27001 certified’, organisations get certified, not systems
Right: ‘System implements ISO 27001:A.5.x controls within our certified ISMS’

Framework selection criteria

Organisational context:

Regulatory requirements (NIS2 → ISO 27001; NERC CIP → NIST 800-53)
Industry sector (manufacturing → IEC 62443; financial → ISO 27001 + local regulations)
Certification needs (external audit requirements drive ISO 27001)
Geographic scope (EU → ISO 27001; US → NIST; global → consider both)
Organisational maturity (CIS Controls for organisations starting security programs)

System context:

IT vs. OT systems (OT → IEC 62443 essential; IT → ISO/NIST)
Cloud vs. on-premise (Cloud → CSA CCM relevant alongside primary framework)
System criticality (high criticality → comprehensive frameworks)
Data sensitivity (PCI data → PCI DSS mandatory; health data → HIPAA if US)
Integration complexity (many integrations → framework alignment critical)

Resource considerations:

Available security expertise (complex frameworks need expertise)
Tool support for framework (GRC tools, automation)
External consultant availability (for specialised frameworks)
Audit and assessment costs (ongoing certification expense)
Ongoing maintenance effort (framework updates, control reviews)

Framework mapping and control libraries

Frameworks overlap significantly in core areas:

ISO 27001 ←→ NIST CSF 2.0 (70-90% overlap in core areas like access control, monitoring, incident response)
ISO 27001 ←→ IEC 62443 (complementary: ISMS governance + OT-specific requirements)
NIST CSF ←→ NIST 800-53 (CSF references 800-53 controls for implementation)
CIS Controls → All frameworks (CIS provides mapping to ISO, NIST, and others)

Threat: unauthorised access to confidential data

Framework mappings for single organisational control ‘User Access Management’:

ISO 27001:2022 → A.5.15, A.5.16, A.5.17, A.5.18 (Access control theme)
NIST CSF 2.0 → PR.AC-1 through PR.AC-7 (Protect: Access Control)
IEC 62443-3-3 → FR 1 (Identification & Authentication), FR 2 (Use Control)
CIS Controls → 5 (Account Management), 6 (Access Control Management)
NIST 800-53 → AC-2, AC-3, AC-6, IA-2, IA-5 (Access Control family)

Single organisational control implementation satisfies requirements from five frameworks simultaneously.

Control library structure:

Control Catalog: What controls exist, categorised by domain
Implementation Guidance: How to implement each control
Framework Mapping: Which framework requirements each control satisfies
Control Templates: Standard implementation patterns
Evidence Requirements: What evidence demonstrates implementation
Ownership and Review: Who owns control, review frequency

Control categorisation:

By function: Preventive, Detective, Corrective
By domain: Technical, Administrative, Physical
By tier: Baseline, Enhanced, Advanced

Control documentation example:

## ORG-AC-001: User Access Provisioning and De-provisioning
 
Control Type: Preventive, Administrative
Control Tier: Baseline (all systems)
Control Owner: IT Operations Manager
Review Frequency: Annual
 
Framework Mapping:
- ISO 27001:2022: A.5.16 (Identity management)
- NIST CSF 2.0: PR.AC-1 (Identities and credentials managed)
- IEC 62443-3-3: FR 2.1 (Authorization enforcement)
- CIS Control: 5.1, 5.3 (Account management)
- NIST 800-53: AC-2 (Account Management)
 
Control Objective:
Ensure user access is granted based on business need and revoked promptly upon role change or separation.
 
Implementation Guidance:
1. User access request via ServiceNow ticket
2. Manager approval required for all access
3. Role-based access assignment (no direct permissions)
4. Access review quarterly for all users
5. Automated de-provisioning on HR termination event
 
Evidence Types:
- Access request tickets
- Approval records
- Access review reports
- Termination audit logs
 
Tier-Specific Requirements:
- Baseline (all systems): Manager approval + quarterly review
- Enhanced (elevated risk): + Automated provisioning workflow
- Advanced (critical systems): + Privilege escalation workflow + continuous access monitoring

Control selection for system security concepts

Control selection process:

Identify applicable frameworks (regulatory, certification, industry)
Assess system risk and criticality → Determine control tier
Select framework controls applicable to system context
Map to organisational control library
Identify control gaps (required but not yet implemented)
Document control rationale (why this control for this threat)
Define implementation approach (inherit, adapt, custom)

Systems inherit controls from four sources:

Enterprise capabilities: SIEM, IAM, DLP, where the system inherits organisational implementation
Shared infrastructure: network security, physical security, where the system operates within existing controls
Platform controls: cloud provider controls, OS hardening, where the system is built on a secure platform
System-specific controls: application-level, data-specific, where the system implements unique requirements

Document inheritance explicitly:

## Access Control Implementation
 
Enterprise Capability Inheritance:
- Authentication: Inherits from Azure AD enterprise SSO
- Authorization: Leverages Azure AD group-based RBAC
- MFA: Enforced by Azure AD conditional access policies
- Access Reviews: Conducted by IT Operations per ORG-AC-001
 
System-Specific Controls:
- Application-level role definitions (Sales, Manager, Admin)
- Data-level access restrictions (customer data visibility by region)
- Privileged function authorization (approve orders >€10,000)

When standard controls don’t fit, compensating controls provide an alternative.

Some systems can’t implement standard controls due to technical constraints, legacy architecture, or operational requirements. Compensating controls provide equivalent protection through different means.

Compensating control requirements:

Document why standard control can’t be implemented
Define alternative control providing equivalent protection
Demonstrate equivalency (addresses same threat with similar effectiveness)
Risk acceptance for any residual gap

Example:

Standard Control: “System must integrate with enterprise SSO” Constraint: “Legacy SCADA application doesn’t support SAML/OIDC” Compensating Control: “Local authentication with strong password policy + MFA via hardware token + enhanced logging to SIEM + monthly access review” Equivalency Justification: “Combination of strong authentication, MFA, monitoring, and frequent review provides equivalent assurance to SSO integration” Residual Risk: “Users maintain separate credentials; no single sign-on convenience” Risk Accepted By: [Business Owner], [CISO]

IEC 62443 deep-dive: OT/ICS security

Manufacturing, process industries, and critical infrastructure require IEC 62443, the OT/ICS security standard series.

IT security frameworks (ISO 27001, NIST) focus on data confidentiality. OT security prioritises safety and availability. A breach in IT might leak customer data. A breach in OT might cause physical harm, environmental damage, or production stoppage worth millions per hour.

IEC 62443 addresses this through:

Zone and conduit segmentation model (network architecture)
Security levels (SL-T, SL-A, SL-C) defining protection intensity
Role separation (Asset Owner, System Integrator, Component Supplier)
Safety-security integration (security that doesn’t compromise safety)

Zones are network segments grouping assets with similar security requirements and criticality. Conduits are controlled communication paths between zones.

Example manufacturing architecture:

Zone 0 (Safety): Emergency shutdown systems, safety PLCs (SL-T 3)
    ↕ Conduit: Unidirectional gateway (safety → process)
Zone 1 (Process Control): DCS, process PLCs, HMI (SL-T 2)
    ↕ Conduit: Industrial firewall + protocol inspection
Zone 2 (Supervisory): SCADA, historians, MES (SL-T 2)
    ↕ Conduit: DMZ with OT firewall
Zone 3 (Enterprise): ERP, maintenance systems (SL-T 1)

Each zone has target security level (SL-T) based on consequence of compromise. Conduits enforce security policies between zones.

Seven foundational requirements (IEC 62443-3-3):

FR 1: Identification and Authentication Control
FR 2: Use Control (Authorization)
FR 3: System Integrity
FR 4: Data Confidentiality
FR 5: Restricted Data Flow (Network Segmentation)
FR 6: Timely Response to Events
FR 7: Resource Availability

Each FR has security levels (SL 1-4) with increasing rigor:

SL 1: Protection against casual or coincidental violation
SL 2: Protection against intentional violation using simple means
SL 3: Protection against intentional violation using sophisticated means
SL 4: Protection against intentional violation using sophisticated means with extended resources

Security levels, SL-T, SL-A, and SL-C:

SL-T (Target): required security level for zone based on risk assessment
SL-A (Achieved): security level actually achieved by system implementation
SL-C (Capability): security level capability of individual components/products

System security concept documents:

SL-T per zone (from risk assessment)
SL-A validation approach (how to demonstrate achievement)
Component SL-C requirements (what products must support)
Gap analysis if SL-A < SL-T (compensating controls or risk acceptance)

Organisations with both IT and OT:

ISO 27001 (Organisational ISMS):

Organisational security governance
Risk management methodology
Policy framework
Applies to all information assets (IT and OT)

IEC 62443-2-1 (Asset Owner Program):

OT/ICS-specific security program within ISMS
Addresses OT unique requirements (safety, availability priority)
Defines zones, SL-T targets, OT-specific controls

IEC 62443-3-3 (System Requirements):

Applied to specific OT systems
Documents zone architecture, security levels, control implementation
Referenced in system security concepts for OT systems

Result: Integrated governance (ISO 27001) with OT-specific requirements (IEC 62443).

Common pitfalls and how to avoid them

Organisations frequently select frameworks because competitors use them, without assessing context fit. Others attempt to implement all controls from all frameworks simultaneously, creating unsustainable compliance burden. Some choose frameworks without considering future audit or certification needs, forcing costly rework later.

Effective framework selection considers regulatory requirements first, then industry alignment, organisational maturity, and available resources. The framework should support your compliance obligations while matching your capability to implement and maintain controls.

The most common mistake is copy-pasting framework controls without organisational adaptation. Generic controls from frameworks don’t account for your specific technology stack, organisational structure, or risk appetite. Another pitfall is creating overly detailed controls that look impressive but are never maintained, becoming shelf-ware within months. Many organisations also fail to assign clear ownership or establish review schedules, leaving controls orphaned.

Start with baseline controls aligned to critical risks. Mature incrementally based on lessons learned. Assign clear ownership for each control with defined review cycles. Maintain controls actively: treat them as living documentation, not compliance artefacts.

Many organisations apply all organisational controls to all systems regardless of risk level, creating unnecessary overhead for low-risk systems while diluting focus on critical assets. Without a control inheritance model, every system documents everything from scratch, duplicating effort and creating inconsistency. Weak rationale for control selection, typically ‘the framework says so’, can’t be justified to auditors who ask why specific controls apply to specific systems.

Implement risk-based tiering where control intensity matches system criticality. Establish clear inheritance models so systems can reference enterprise capabilities rather than documenting everything locally. Document threat-to-control mapping that shows which controls mitigate which threats in your specific context.

Integration with system security concepts

Control libraries enable system security concepts:

In the design phase, system risk assessment determines control tier (baseline/enhanced/advanced). The system inherits controls from the organisational library for that tier. The security concept documents system-specific implementation.

In the implementation phase, track control deployment status against the inherited control set. The security concept references the organisational control library, documenting what’s implemented vs. in progress.

In operations, system changes are assessed against control requirements. If a change affects controls, the security concept is updated. The control library provides a stable baseline; the security concept documents system-specific variations.

For audits, the control library provides centralised framework mapping. Auditors review the organisational control library once. System security concepts demonstrate how each system implements inherited controls, enabling efficient audits with consistent evidence.

For portfolio view, stack all security concepts together. See which controls are widely deployed vs. gaps. Identify systems with similar risk profiles but inconsistent controls. Guide investment to close gaps.

Control libraries transform security concepts from per-system invention to systematic inheritance with system-specific adaptation. Consistency, efficiency, proportionate response.

Conclusion

Control selection isn’t arbitrary, it maps business needs to threats to controls with documented rationale. Security frameworks provide structured approaches, proven controls, and compliance evidence.

Build organisational control libraries mapped to frameworks. Tier controls by risk. Systems inherit based on criticality. This is proportionate response at scale.

ISO 27001 governs organisational ISMS; ISO 27002 guides system implementation. NIST CSF provides enterprise risk language; NIST 800-53 provides controls. IEC 62443 addresses OT/ICS unique requirements. CIS Controls prioritise implementation for resource-constrained organisations.

Select frameworks based on regulatory requirements, industry context, and organisational maturity. Map controls across frameworks to avoid duplication. Build inheritance models so systems leverage enterprise capabilities.

Article 4 addresses the living document challenge: security concepts must adapt as systems, threats, and business requirements evolve. How to integrate with change management, what triggers updates, and how to prevent documentation drift.

Next in series: Article 4 - The Living Document: Lifecycle and Change Management

Article 3 of 7 | Ready for publication Target audience: Security Architects, CISO, Senior Security Specialists Word count: ~2,980

Sten Eikrem - Information Security & Risk Management

Explorer