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 Doctrine: Proportionate Response

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

Start with Business Needs, Not Technical Controls

Control selection begins with three questions:

1. 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)

2. 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 organizational risk management)

3. 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

Why Ad-Hoc Control Selection Fails

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 → security properties → threats → 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 organizations. 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.

Organizational Control Libraries: Reuse Over Reinvention

Rather than selecting controls from scratch for every system, build an organizational 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 organized 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 organizational 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	Organizational ISMS standard	ISMS governance, certification, risk management	Yes (organizational 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 organization, 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	Prioritized control set	Implementation prioritization, resource-constrained	No	Prioritization (IG1/IG2/IG3), actionability

ISO 27001 vs. ISO 27002: Organizational Governance vs. System Implementation

ISO 27001 builds organizational 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 (Organizational ISMS Framework):

• Certifiable standard for organizational 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 organizational 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.

Organizational vs. System Level Framework Applicability

Different frameworks apply at different levels:

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

Common mistakes:

• ❌ “We implement NIST CSF at system level” - CSF is an enterprise risk framework

• ✅ “System implements NIST 800-53 controls that support NIST CSF Protect function”

• ❌ “Our system is ISO 27001 certified” - Organizations get certified, not systems

• ✅ “System implements ISO 27001:A.5.x controls within our certified ISMS”

---

Framework Selection Criteria

Organizational 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)
• Organizational maturity (CIS Controls for organizations 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 specialized frameworks)
• Audit and assessment costs (ongoing certification expense)
• Ongoing maintenance effort (framework updates, control reviews)

---

Framework Mapping and Control Libraries

Framework Relationships

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)

Practical Multi-Framework Mapping Example

Threat: Unauthorized access to confidential data

Framework mappings for single organizational 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 organizational control implementation satisfies requirements from five frameworks simultaneously.

Building Organizational Control Libraries

Control library structure:

• Control Catalog: What controls exist, categorized 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 categorization:

• 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

From Framework to System

Control selection process:

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

Control Inheritance

Systems inherit controls from four sources:

Enterprise capabilities: SIEM, IAM, DLP → system inherits organizational implementation Shared infrastructure: Network security, physical security → system operates within existing controls Platform controls: Cloud provider controls, OS hardening → system built on secure platform System-specific controls: Application-level, data-specific → 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

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.

Why IEC 62443 is Different

IT security frameworks (ISO 27001, NIST) focus on data confidentiality. OT security prioritizes 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)

Zone and Conduit Model

Zones: Network segments grouping assets with similar security requirements and criticality Conduits: 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, 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)

Integrating IEC 62443 with ISO 27001 ISMS

Organizations with both IT and OT:

ISO 27001 (Organizational ISMS):

• Organizational 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

Framework Selection Mistakes

❌ Selecting framework because competitors use it without assessing context fit ❌ Attempting to implement all controls from all frameworks simultaneously ❌ Choosing framework without considering audit/certification needs ✅ Select based on: regulatory requirements + industry alignment + maturity + resources

Control Library Development Mistakes

❌ Copy-pasting framework controls without organizational adaptation ❌ Creating overly detailed controls that are never maintained ❌ No clear ownership or review schedule ✅ Start with baseline controls, mature incrementally, assign clear ownership, maintain actively

System-Level Control Selection Mistakes

❌ Applying all organizational controls to all systems regardless of risk ❌ No control inheritance model (every system documents everything) ❌ Weak rationale for control selection (can’t justify to auditors) ✅ Risk-based tiering, clear inheritance model, documented threat-to-control mapping

---

Integration with System Security Concepts

Control libraries enable system security concepts:

Design Phase: System risk assessment determines control tier (baseline/enhanced/advanced). System inherits controls from organizational library for that tier. Security concept documents system-specific implementation.

Implementation Phase: Track control deployment status against inherited control set. Security concept references organizational control library, documents what’s implemented vs. in progress.

Operations: System changes assessed against control requirements. If change affects controls, security concept updated. Control library provides stable baseline; security concept documents system-specific variations.

Audits: Control library provides centralized framework mapping. Auditors review organizational control library once. System security concepts demonstrate how each system implements inherited controls. Efficient audit with consistent evidence.

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 organizational control libraries mapped to frameworks. Tier controls by risk. Systems inherit based on criticality. This is proportionate response at scale.

ISO 27001 governs organizational 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 prioritize implementation for resource-constrained organizations.

Select frameworks based on regulatory requirements, industry context, and organizational 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