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 modelling, 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 modelling provides no rationale for controls. Threat modelling without risk assessment can’t prioritise. 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.
Start by describing the system’s business purpose in language business stakeholders recognise. 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.
User populations determine access control requirements, authentication strength, and authorisation 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.
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.
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 organisational 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 decisions 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 modelling 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 modelling: understanding what can go wrong
Threat modelling identifies what can go wrong and who might cause it. This informs control selection and risk assessment.
Organisations approach threat modelling with varying rigour. 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.
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)
Different threat actors have different capabilities and motivations. This affects both likelihood and impact.
Opportunistic attackers use automated scanning, known vulnerabilities, and default credentials. High volume, low sophistication. Prevented by basic security hygiene.
Financially motivated attackers target payment data, credentials, and personally identifiable information. Moderate sophistication, persistent. Prevented by defence in depth.
Competitors target intellectual property, strategic information, and customer data. High sophistication, patient. Require advanced controls and monitoring.
Nation-state actors target critical infrastructure, sensitive data, and strategic systems. Very high sophistication, unlimited resources. Require security-by-design and continuous monitoring.
Insiders have privileged access, knowledge of controls, and 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.
Generic threats like ‘unauthorised 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.
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.
The business perspective asks what harm occurs when the threat materialises. Revenue loss, regulatory fines, customer churn, operational disruption, reputational damage. This answers ‘what do we lose?’
The technical perspective asks 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.
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 modelling.
| 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.
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.
Consider a customer relationship management system as an example. 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 modelling, compliance obligations, and organisational security policies.
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 sanitise all user input’ → Requirement: ‘Application must use parameterised queries for database access’ → Requirement: ‘Database must implement least-privilege access controls’
Multiple requirements may address a single threat. This is defence in depth: if one control fails, others provide backup protection.
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.
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.
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, authorisation 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 analysed by SAST tool (SonarQube) in CI/CD pipeline. Remediation tracked in JIRA per organisational 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?
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 modelling 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?
Use the organisational 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 risk is the risk before implementing controls (threat + vulnerability + impact).
Residual risk is the 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, parameterised 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.
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 theatre 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.
-
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
- Categorised 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
Include information that enables decision-making, audit verification, and maintenance: business context, threat scenarios, control rationale, risk decisions, and accountability. Exclude generic security principles, reproduced framework content, implementation details better documented in architecture docs, and tutorial content.
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.
Structure enables different stakeholders to find their information. Executives read system context, risk assessment summary, and accepted risks. Security reviewers examine the threat model, security requirements, and enterprise capability integration. Auditors review control implementation status, compliance mapping, and evidence references. Architects review security requirements, implementation approach, and 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
### 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]Creating threat scenarios: a practical approach
Threat scenarios connect abstract threats to concrete business consequences. Effective scenarios follow a structured approach from threat actors through vulnerabilities to loss events.
Start with business-level threat actors. For global manufacturing, the primary threat is typically financially motivated criminals targeting operational disruption, ransomware, or data theft. Then consider system-specific threat actors based on system properties:
- Insiders: Systems with privileged access to sensitive data or critical operations
- Competitors: Systems containing intellectual property or strategic information
- Activists: Systems visible to the public or associated with controversial operations
- Nation-state: Critical infrastructure or systems with national security implications
Most systems face criminals and insiders as primary threats. Document why other threat actors are out of scope if they’re not relevant.
System assets exist within enterprise asset ecosystems. A customer database isn’t just ‘customer data’, it connects to enterprise identity systems, backup infrastructure, monitoring platforms, and network segments.
Document both:
- System assets: Data, applications, infrastructure directly part of this system
- Enterprise assets: IAM, SIEM, network, backup that this system depends on
Understanding enterprise asset dependencies reveals how attackers pivot from system compromise to broader enterprise impact.
Focus on the five most likely scenarios that represent your primary risk exposure. ‘Most likely’ implicitly considers both probability and impact: a low-probability but catastrophic scenario can be ‘most likely to matter’ for risk management.
For each scenario, follow the threat model structure:
- Threat Actor: identifies who
- Threat (Action): describes what they do
- Vulnerabilities: explains what weaknesses enable it
- Asset: specifies what’s compromised
- Consequence: describes the chain of events
- Impact (Loss Event): quantifies business harm
Five well-crafted scenarios covering different attack patterns provide better risk coverage than fifteen generic scenarios.
Detailed attack paths are valuable but maturity-dependent. Organisations new to threat modelling should start with high-level scenarios describing the threat actor, objective, general approach, and business impact. As maturity grows, add attack path detail.
High-level scenario: ‘Ransomware deployed via phishing, encrypts production databases, causes 3-day production outage, €2M revenue loss.’
Detailed scenario: Maps specific attack chain including initial access vector, privilege escalation technique, lateral movement path, persistence mechanism, and execution timeline.
Start high-level. Add detail as your threat modelling maturity and defensive capabilities evolve.
Every threat scenario must connect to business loss events. Without loss events, you can’t discuss risk, you’re just describing technical vulnerabilities. Loss events quantify harm in business terms: revenue loss, regulatory fines, operational disruption duration, customer churn rate, incident response costs.
The top 5 scenarios implicitly incorporate probability: these are the scenarios most likely to occur or most likely to create material impact. Detailed probability analysis can follow, but effective threat scenarios start with clear consequence-to-impact chains.
## Threat Scenario: [Descriptive Name]
**Threat Actor**: [Financially Motivated Criminals/Insider/Competitor/Nation-State]
**Motivation**: [What attacker gains - money/IP/disruption/strategic advantage]
**Threat (Attack Action)**:
[Describe the attack - phishing campaign, SQL injection, supply chain compromise, etc.]
**Vulnerabilities Exploited**:
- [Technical weakness 1 - missing patch, misconfiguration, architecture flaw]
- [Technical weakness 2 - inadequate monitoring, weak authentication]
- [Process weakness - if applicable]
**Asset(s) Affected**:
- System: [Application/database/infrastructure component]
- Data: [Customer records/financial data/IP/operational data]
- Enterprise: [Connected systems or capabilities impacted]
**Consequence Chain**:
1. [Immediate effect - data exfiltration/system encryption/access gained]
2. [Secondary effect - service disruption/data corruption/lateral movement]
3. [Tertiary effect - business process failure/regulatory notification required]
**Impact (Loss Event)**:
- **Financial**: [€X revenue loss, €Y remediation costs, €Z regulatory fines]
- **Operational**: [X days disruption, Y systems affected, Z customers impacted]
- **Regulatory**: [GDPR breach notification, ISO certification suspension, industry reporting]
- **Reputational**: [Customer churn estimate, media coverage, competitive disadvantage]
**Existing Controls** (what reduces likelihood or impact):
- [Control 1 - how it helps]
- [Control 2 - how it helps]
**Control Gaps** (what's missing):
- [Gap 1 - why scenario remains plausible]
- [Gap 2 - what could prevent or detect]
**Residual Risk**: [Low/Medium/High/Critical - after existing controls considered]## 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 modelling, 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 modelling 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 organisational 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