Core Components: What Makes a Security Concept Effective
Article 2 of 7 in the System Security Concepts series
Introduction
Article 1 established what security concepts are and why they matter. This article examines what makes a security concept effective—the core components that enable it to function as both a governance instrument and a communication bridge.
An effective security concept has five essential components: system context, threat modeling, security requirements, risk assessment, and documentation structure. Each component serves a specific purpose. Together, they create a complete view of system security that stakeholders can understand, auditors can verify, and architects can implement.
Missing any component weakens the whole. System context without threat modeling provides no rationale for controls. Threat modeling without risk assessment can’t prioritize. Risk assessment without security requirements can’t be implemented. Security requirements without documentation structure can’t be maintained.
This article examines each component in turn, showing how they connect and what makes them work in practice.
System Context: The Foundation
Every security concept begins with system context. This answers four questions: What does the system do? Who uses it? What data does it handle? Why does it matter to the business?
These aren’t security questions—they’re business questions. Yet security decisions flow directly from the answers.
What the System Does
Describe the system’s business purpose in language business stakeholders recognize. Avoid technical architecture unless it’s relevant to security decisions.
Good: “Customer relationship management system supporting sales teams across 15 countries. Handles customer contacts, opportunity tracking, contract management, and revenue forecasting.”
Poor: “Three-tier web application using React frontend, Node.js backend, PostgreSQL database, deployed on AWS ECS with CloudFront CDN.”
The technical architecture belongs in a separate section. The system overview establishes business purpose.
Who Uses It
User populations determine access control requirements, authentication strength, and authorization granularity.
Different user populations create different security profiles:
- Internal employees: Trust level, network location, device management
- External partners: Limited trust, contract-based access, third-party systems
- Customers: Minimal trust, self-service, public internet
- Administrators: Privileged access, audit requirements, segregation of duties
- Automated systems: API authentication, rate limiting, monitoring
Document the number of users in each population and their geographic distribution. This informs capacity planning for authentication systems and network security architecture.
What Data It Handles
Data classification drives most security decisions. Yet organisations often struggle to classify system data accurately.
The challenge isn’t defining classification schemes—most organisations have policies defining public, internal, confidential, and restricted data. The challenge is applying those classifications to actual system data and understanding the consequences.
Effective data classification in security concepts answers three questions:
What’s the highest classification level? This establishes the security baseline. A system processing restricted data requires controls appropriate for that classification, even if 99% of its data is internal.
What’s the volume distribution? A system with primarily public data but occasional confidential records needs different controls than one where confidential data is the norm. The proportionality matters.
What are the specific data elements? Generic terms like “customer data” provide insufficient guidance. Be specific: names, addresses, purchase history, payment card numbers, health records, biometric data. Different data elements trigger different regulatory requirements.
Why It Matters to Business
Business criticality determines how much security is proportionate. A system supporting revenue-generating operations warrants different investment than back-office tooling.
Criticality has multiple dimensions:
Revenue impact: Would system failure directly affect revenue? Payment systems, e-commerce platforms, and customer-facing services have immediate revenue impact.
Operational impact: Would failure disrupt critical business processes? Manufacturing control systems, supply chain platforms, and communication tools have high operational impact even without direct revenue consequences.
Regulatory impact: Would failure create regulatory violations or reporting obligations? Systems processing personal data, financial records, or safety-critical information carry regulatory risk independent of revenue or operations.
Reputational impact: Would failure damage organizational reputation or customer trust? High-profile systems, customer data repositories, and public-facing services carry reputational risk that outlasts the incident.
Document the recovery time objective (RTO) and recovery point objective (RPO) if defined. These indicate how much downtime and data loss the business can tolerate, which drives availability and backup requirements.
Architectural Context Matters
Architectural decisions fundamentally shape the threat landscape. A customer portal implemented as SaaS faces different threats than the same portal cloud-hosted or on-premise. The security concept must analyse the actual system design, not generic architectural assumptions.
Document:
- Hosting model: SaaS, PaaS, IaaS, on-premise, hybrid
- Technology stack: Cloud-native, containerised, traditional, serverless
- Supplier dependencies: Which security controls rely on third parties
- Responsibility boundaries: Who controls physical security, infrastructure, platform, application, data
This context enables threat modeling that reflects architectural realities rather than generic scenarios. A misconfigured S3 bucket is a relevant threat for cloud-hosted systems but meaningless for on-premise deployment. Conversely, physical data centre breach is irrelevant for SaaS but critical for on-premise.
System criticality and data classification drive security requirements. Hosting model determines HOW you implement controls, not WHETHER you need them. A high-criticality SaaS system requires rigorous security analysis just like a high-criticality on-premise system—the threats and controls differ in implementation, not in necessity.
Threat Modeling: Understanding What Can Go Wrong
Threat modeling identifies what can go wrong and who might cause it. This informs control selection and risk assessment.
Organisations approach threat modeling with varying rigor. Some conduct formal workshops using STRIDE, PASTA, or attack trees. Others take lightweight approaches, identifying obvious threats based on system characteristics. Both work if they produce actionable output.
Avoid Analysis Paralysis
The goal is adequate threat identification, not exhaustive threat enumeration. Perfect is the enemy of good. A threat model that captures the major threats and gets reviewed is more valuable than a comprehensive threat model that never gets maintained.
Focus on threats that are:
- Relevant to the specific system (not generic security threats)
- Plausible given the threat actor landscape (not theoretical)
- Actionable (you can implement controls against them)
Threat Actors and Motivation
Different threat actors have different capabilities and motivations. This affects both likelihood and impact.
Opportunistic attackers: Automated scanning, known vulnerabilities, default credentials. High volume, low sophistication. Prevented by basic security hygiene.
Financially motivated attackers: Targeting payment data, credentials, personally identifiable information. Moderate sophistication, persistent. Prevented by defense in depth.
Competitors: Targeting intellectual property, strategic information, customer data. High sophistication, patient. Require advanced controls and monitoring.
Nation-state actors: Targeting critical infrastructure, sensitive data, strategic systems. Very high sophistication, unlimited resources. Require security-by-design and continuous monitoring.
Insiders: Privileged access, knowledge of controls, ability to cover tracks. Require separation of duties, monitoring, and access reviews.
For most systems, the first two categories represent the primary threat. Document why you believe certain threat actor categories are out of scope, but don’t ignore them without rationale.
From Threats to Attack Scenarios
Generic threats like “unauthorized access” provide limited value. Attack scenarios make threats concrete.
Generic: “Risk of data breach”
Specific: “Attacker exploits SQL injection vulnerability in customer search function to extract database contents including customer names, addresses, and payment card numbers. Discovery occurs when customer receives fraudulent charges and traces back to recent purchase.”
The specific scenario enables stakeholders to understand the threat, evaluate the business impact, and assess whether proposed controls actually prevent it.
Focus on 5 well-crafted scenarios covering your major threat categories. Quality matters more than quantity. Five specific, actionable scenarios that stakeholders can understand and that inform control selection are more valuable than fifteen generic scenarios that create review burden without adding insight.
Business and Technical Perspectives on Risk
Every risk has two essential perspectives - the business impact and the technical cause. These aren’t separate risks. They’re two views of the same risk event.
Business perspective: What harm occurs when the threat materializes? Revenue loss, regulatory fines, customer churn, operational disruption, reputational damage. This answers “what do we lose?”
Technical perspective: What technical failure enables the threat? Vulnerability, misconfiguration, inadequate monitoring, missing control, architecture weakness. This answers “why are we vulnerable?”
Neither perspective is meaningful without the other. Describing business impact without technical cause provides no path to mitigation. Describing technical vulnerabilities without business impact provides no rationale for investment.
Both perspectives must appear in the security concept. Business impact communicates to executives and business owners, justifying security investment. Technical causes guide architects and implementers, showing what must be fixed. Together, they create complete understanding of the risk.
How Architectural Choices Transform Threats
Security concepts analyse the specific system design, not generic architectural patterns. The same business function implemented differently has a different threat profile. SaaS, cloud-hosted, and on-premise variants of the same system face distinct threats.
Architectural choices don’t eliminate threats—they transform them. They shift where vulnerabilities can exist, who is responsible for controls, what attack surface is exposed, and how threats materialise. Understanding this transformation is essential for effective threat modeling.
| Threat Category | SaaS (e.g., Salesforce) | Cloud-Hosted (e.g., Azure PaaS) | On-Premise |
|---|---|---|---|
| Unauthorised Data Access | Misconfigured sharing rules, weak SSO integration | Application vulnerability, misconfigured RBAC, Azure AD compromise | Network breach, application vulnerability, stolen credentials |
| Data Breach | SaaS provider breach (rely on vendor security), compromised admin account | Storage misconfiguration, application vulnerability, compromised Azure subscription | Perimeter breach, insider threat, backup theft |
| Data Loss | SaaS provider outage, accidental deletion (rely on vendor backup) | Misconfigured backup, region failure, storage account deletion | Hardware failure, backup failure, disaster |
| Availability (DoS) | SaaS provider capacity limits, upstream outages | Azure service limits, DDoS (Azure provides protection), application-layer DoS | Network capacity, infrastructure capacity, application-layer DoS |
| Insider Threat | Same across all - authorised user abuse | Same across all | Same across all |
| Supply Chain Attack | SaaS provider compromise, third-party integration | Cloud provider compromise, dependency compromise | On-premise software vendor, dependency compromise |
Notice how insider threat and business logic flaws persist regardless of architectural choices. Hosting model changes attack vectors but doesn’t eliminate fundamental threats. A phishing attack targeting CRM users works equally well whether the CRM is SaaS, cloud-hosted, or on-premise.
Control Responsibility Transformation
Different architectures shift security responsibility:
| Control Category | SaaS | Cloud-Hosted | On-Premise |
|---|---|---|---|
| Physical Security | Vendor | Cloud provider | Organisation |
| Infrastructure Patching | Vendor | Shared (OS: organisation, hypervisor: provider) | Organisation |
| Application Security | Shared (vendor provides platform, org configures) | Organisation | Organisation |
| Data Encryption | Vendor provides (org configures) | Organisation configures (cloud provides primitives) | Organisation implements |
| Access Control | Organisation configures | Organisation implements | Organisation implements |
| Business Logic Security | Organisation across all | Organisation across all | Organisation across all |
Security concepts must document these responsibility boundaries explicitly. When you rely on a third party for physical security, infrastructure patching, or platform security, you inherit both their capabilities and their limitations. Document what you control, what you inherit, and what gaps require compensating controls.
Example: Customer Relationship Management System
Business requirement: CRM handling confidential customer data System criticality: High (revenue-impacting, confidential data)
Scenario A: SaaS (Salesforce)
- Threat focus: Misconfigured sharing rules, weak SSO integration, vendor breach, unauthorised API access, excessive user permissions
- Control emphasis: Salesforce Shield Platform Encryption, SSO configuration, user provisioning automation, Salesforce-to-SIEM log forwarding, quarterly permission reviews
- Dependency: Rely on Salesforce for platform security, infrastructure security, physical security, disaster recovery
- Gaps: Cannot implement custom encryption, cannot control Salesforce patching schedule, limited visibility into platform-level security events
Scenario B: Cloud-Hosted (Azure SQL + App Services)
- Threat focus: Application vulnerabilities, Azure misconfiguration, compromised subscription credentials, publicly exposed database, OWASP Top 10
- Control emphasis: Application security (SAST/DAST in pipeline), Azure security posture management, network isolation (private endpoints), database Transparent Data Encryption, Azure AD Conditional Access
- Dependency: Rely on Azure for infrastructure, hypervisor security, physical security, implement application and data protection
- Gaps: Cannot inspect Azure hypervisor security, rely on Microsoft for infrastructure patching, Azure service limits constrain some security controls
Scenario C: On-Premise (Traditional data centre)
- Threat focus: Network perimeter breach, insider threat, physical security, infrastructure vulnerabilities, patch management gaps, backup security
- Control emphasis: Network firewalls, IDS/IPS, physical access control, systematic patch management, encrypted backups, full infrastructure monitoring
- Dependency: Full responsibility for all layers from physical to application
- Gaps: Resource-intensive, requires diverse specialist skills, capital investment in redundancy and disaster recovery
Threats that persist regardless of architecture:
- Phishing attacks targeting CRM users
- Insider threat (authorised user data exfiltration)
- Business logic flaws (authorisation bypass allowing users to see competitors’ customer data)
- Social engineering attacks (convincing helpdesk to reset passwords, grant inappropriate access)
- Credential compromise (weak passwords, credential stuffing)
All three variants require security concepts. All three can be implemented poorly or well. The security concept analyses how architectural choices affect threats, controls, and responsibilities—then documents controls appropriate to that specific design.
Poor implementation makes any architecture insecure. Good implementation makes any architecture defensible within its inherent constraints. The security concept captures this analysis and guides implementation accordingly.
Security Requirements: Translating Threats to Controls
Security requirements specify what controls the system must implement. Requirements flow from three sources: threats identified in threat modeling, compliance obligations, and organizational security policies.
Linking Threats to Requirements
Every significant threat should map to one or more security requirements. This traceability enables stakeholders to understand why each requirement exists.
Example mapping:
Threat: “Attacker exploits SQL injection to extract customer data” → Requirement: “Application must validate and sanitize all user input” → Requirement: “Application must use parameterized queries for database access” → Requirement: “Database must implement least-privilege access controls”
Multiple requirements may address a single threat. This is defense in depth—if one control fails, others provide backup protection.
High-Level Requirements, Not Implementation
Security requirements in the security concept should specify what security outcomes the system must achieve, not how to implement them.
Good: “System must enforce multi-factor authentication for all user access”
Poor: “System must integrate with Okta using SAML 2.0 protocol with SHA-256 signatures”
The first is a requirement. The second is an implementation detail. Implementation details belong in architecture documentation, not security requirements.
This distinction matters because requirements remain stable while implementations change. When you migrate from Okta to Azure AD, the requirement (MFA for all users) doesn’t change. Only the implementation changes.
Control Framework References
Article 3 covers control framework selection in depth. In the security concept, reference applicable framework controls without reproducing their content.
Format for framework references:
“This requirement satisfies ISO 27001:A.5.15 (Access control) and NIST CSF PR.AC-1 (Identity and credential management). Implementation follows ISO 27002:5.15 guidance.”
This approach provides audit traceability while keeping the security concept maintainable. When ISO 27001 control numbers change, you update references, not entire control descriptions.
Enterprise Capability Integration
The single most common gap in security concepts is missing enterprise capability integration.
Most organisations have enterprise security capabilities: IAM/SSO, SIEM, vulnerability management, incident response, DLP, endpoint protection, network security. Systems should leverage these capabilities rather than implement duplicate controls.
Document enterprise capability integration explicitly:
Authentication: “System integrates with enterprise SSO (Azure AD) for user authentication. No local authentication database. MFA enforced by Azure AD conditional access policies.”
Monitoring: “System logs authentication events, authorization decisions, and data access to enterprise SIEM (Splunk). Security team monitors for anomalous activity using established playbooks.”
Vulnerability management: “System infrastructure scanned by enterprise vulnerability management (Qualys). Application code analyzed by SAST tool (SonarQube) in CI/CD pipeline. Remediation tracked in JIRA per organizational SLA.”
This integration serves three purposes. First, it prevents control duplication—don’t build authentication when enterprise SSO exists. Second, it enables portfolio-level visibility—stack all security concepts together and see your actual enterprise architecture. Third, it clarifies dependencies—if enterprise SSO has an outage, which systems are affected?
Gap Analysis
Enterprise capabilities may not cover all requirements. Document gaps and how you address them.
Example: “Enterprise SIEM doesn’t support application-specific audit requirements for financial transaction logging. System implements additional application-layer audit log with 7-year retention to satisfy regulatory requirements. Application audit logs exported to SIEM for security monitoring.”
This transparency enables informed decision-making. The CISO can see where gaps exist. Business owners understand why system-specific controls are necessary. Auditors can verify control implementation.
Risk Assessment: Understanding Residual Risk
Threat modeling identifies what can go wrong. Security requirements specify controls to prevent it. Risk assessment evaluates whether the combination is adequate.
Risk assessment in security concepts addresses two questions: What threats remain after implementing proposed controls? Are residual risks acceptable to the business?
Risk Assessment Methodology
Use the organizational risk assessment methodology if one exists. Don’t invent system-specific risk calculation methods—inconsistent risk assessment across systems prevents portfolio-level comparison.
Most methodologies assess risk using likelihood and impact:
Likelihood: Given the threat actor landscape, system exposure, and implemented controls, how likely is successful attack?
Impact: If the attack succeeds, what business harm occurs? Consider financial, operational, regulatory, and reputational impact.
Common approaches:
- Qualitative: Low/Medium/High/Critical ratings with defined criteria
- Semi-quantitative: Numeric scales (1-5) with rating definitions
- Quantitative: Financial models using FAIR or similar methodologies
Qualitative methods work for most systems. Quantitative methods provide value for high-impact decisions but require significant effort.
Inherent vs. Residual Risk
Inherent risk: Risk before implementing controls (threat + vulnerability + impact)
Residual risk: Risk after implementing controls (inherent risk - control effectiveness)
Both appear in the risk assessment, showing how controls reduce risk.
Example:
Threat: SQL injection enabling data breach Inherent Risk: High (valuable data, common vulnerability, high impact) Controls: Input validation, parameterized queries, least-privilege database access, SIEM monitoring Residual Risk: Low (multiple controls reduce likelihood; impact unchanged but probability significantly reduced)
This transparency enables risk-informed decision-making. Stakeholders see both the risk and how controls address it.
Risk Acceptance
Not all risks can be eliminated. Some controls are too expensive. Some threats are too unlikely. Some impacts are tolerable. These require explicit risk acceptance.
Risk acceptance requires three elements:
- What’s being accepted: Specific threat and potential impact
- Why it’s being accepted: Control cost exceeds risk, threat likelihood very low, business can tolerate impact
- Who accepts it: Named resource owner with authority to accept risk
Risk acceptance authority follows resource ownership. You can only accept risk for resources you control. The system owner who controls budget, architecture decisions, and operational responsibility can accept risk for that system. Security teams can advise and review, but cannot accept risk on behalf of resource owners they don’t control.
Document accepted risks in the security concept. This prevents the same discussion recurring every audit. The resource owner accepted this risk. The CISO reviewed and concurred. The decision is documented.
Risk acceptance isn’t failure, it’s pragmatic risk management. Attempting to eliminate all risk creates security theater and wastes resources. Explicit risk acceptance with business ownership is mature security governance.
Documentation Structure: Making It Maintainable
The best security analysis becomes useless if documented in a way nobody can maintain.
Effective documentation structure balances comprehensiveness with maintainability. Too little structure creates ambiguity. Too much structure creates maintenance burden.
Recommended Structure
-
Document Control
- Version, date, owner, approval status, review schedule
-
System Context
- Business purpose, user populations, data classification, criticality
-
Threat Model
- Threat actors, attack scenarios, assumed threats out of scope
-
Security Requirements
- Categorized by security domain (access control, data protection, monitoring, etc.)
- Framework references (ISO 27001, NIST, etc.)
- Enterprise capability integration
-
Risk Assessment
- Major threats with inherent and residual risk
- Accepted risks with business approval
- Risk treatment plan for unacceptable residual risks
-
Control Implementation Status
- What’s implemented, what’s in progress, what’s planned
- Evidence references for implemented controls
-
Compliance Mapping
- Regulatory requirements (GDPR, NIS2, etc.) mapped to controls
- Audit trail for compliance demonstration
-
Open Items and Remediation
- Known gaps, remediation plans, target dates
- Accountability for closure
-
Approval and Sign-Off
- System owner, security review, risk acceptance
- Formal approval records
What to Include
Include information that enables decision-making, audit verification, and maintenance.
Include: Business context, threat scenarios, control rationale, risk decisions, accountability
Exclude: Generic security principles, reproduced framework content, implementation details better documented in architecture docs, tutorial content
What to Exclude
Don’t reproduce content available elsewhere. Reference policies, standards, and framework documentation rather than copying them into the security concept.
Don’t document temporary conditions that change frequently. Link to external systems of record (JIRA, ServiceNow) for implementation status rather than maintaining parallel tracking in the security concept.
Don’t include extensive tutorial content on how to implement controls. The security concept specifies requirements. Architecture documentation describes implementation.
Keeping It Actionable
Structure enables different stakeholders to find their information:
Executives: Read system context, risk assessment summary, accepted risks Security reviewers: Review threat model, security requirements, enterprise capability integration Auditors: Review control implementation status, compliance mapping, evidence references Architects: Review security requirements, implementation approach, dependencies
Clear structure with distinct sections enables targeted review. Nobody needs to read the entire security concept to find relevant information.
Practical Templates and Examples
Abstract principles need concrete examples. Here are templates for core components.
System Context Template
## System Context
### Business Purpose
[System name] provides [business capability] to [user population]. The system supports [business objective] by enabling [key functionality].
Critical business processes: [list processes that depend on this system]
Geographic scope: [regions/countries where system operates]
Integration dependencies: [upstream/downstream systems]
### User Populations
- Internal users: [number] users across [departments/functions]
- External users: [number] [partners/customers/contractors]
- Administrators: [number] with privileged access
- Automated systems: [number] API consumers
### Data Classification
Highest classification: [Restricted/Confidential/Internal/Public]
Primary data elements: [specific data types, not generic terms]
Data volumes: [records/transactions/storage]
Regulatory scope: [GDPR/HIPAA/PCI DSS/etc. if applicable]
### Business Criticality
Revenue impact: [Direct/Indirect/None]
Operational impact: [Critical/High/Moderate/Low]
Regulatory impact: [reporting obligations if failure occurs]
RTO: [target recovery time]
RPO: [acceptable data loss]Threat Scenario Template
## Threat Scenario: [Descriptive Name]
Threat Actor: [Opportunistic/Financially Motivated/Insider/etc.]
Motivation: [What attacker gains]
Attack Path:
1. [Initial access/compromise]
2. [Privilege escalation/lateral movement]
3. [Objective achievement]
Business Impact:
- Financial: [revenue loss/fines/costs]
- Operational: [disruption duration/scope]
- Regulatory: [violations/reporting]
- Reputational: [customer trust/brand damage]
Affected Assets:
- [Data/systems/infrastructure compromised]
Likelihood: [Low/Medium/High]
Impact: [Low/Medium/High/Critical]
Inherent Risk: [combination]Security Requirement Template
## Requirement: [REQ-ID] [Requirement Name]
Description: [What must be achieved]
Rationale: [Why this is required - threats/compliance/policy]
Framework Mapping:
- ISO 27001: [control references]
- NIST CSF: [function/category/subcategory]
- CIS Controls: [control number]
Implementation Approach:
- Enterprise capability: [name of enterprise service if applicable]
- System-specific: [if not using enterprise capability, why and what]
Evidence: [How compliance is demonstrated]
Status: [Implemented/In Progress/Planned]
Owner: [Accountable party]
Target Date: [If not implemented]Conclusion
Effective security concepts have five essential components: system context, threat modeling, security requirements, risk assessment, and documentation structure. Each serves a specific purpose. Together they enable the security concept to function as governance instrument and communication bridge.
System context establishes what you’re protecting and why it matters. Threat modeling identifies what can go wrong. Security requirements specify controls to prevent it. Risk assessment evaluates whether the combination is adequate. Documentation structure makes it maintainable.
Missing any component weakens the whole. Generic threats without business context don’t inform control selection. Security requirements without threat rationale can’t be explained to auditors. Risk assessments without control implementation status don’t enable decisions.
Article 3 examines control selection and framework mapping in depth—how to build organizational control libraries that systems can inherit, how to select between frameworks, and how to map controls across multiple frameworks for efficiency.
The security concept is only effective if it’s maintained. Article 4 addresses the living document challenge: how to integrate security concepts with system lifecycle, what changes trigger updates, and how to prevent documentation drift.
Next in series: Article 3 - Control Selection and Security Frameworks: Building Your Control Library
Article 2 of 7 | Ready for publication Target audience: Security Architects, Senior Security Specialists, System Architects Word count: ~3,250