ISMS

Writing a Security Concept: Structure and Template for SMEs

TL;DR
  • An IT security concept is the central document describing how an organization protects its information assets against identified risks. It is more operational than a policy statement and more comprehensive than a single topical policy.
  • The outline typically includes: scope, protection objectives, risk analysis, technical and organizational measures, responsibilities, emergency preparedness, and review cycle.
  • The BSI recommends a structured approach in the IT-Grundschutz Compendium that serves well as an orientation framework even without pursuing full BSI certification.
  • For a mid-market company with 50 to 200 employees, an appropriate scope is 25 to 50 pages. What matters is not page count but practical usability.
  • The security concept must be reviewed and updated at least annually and upon significant changes. An outdated security concept is worse in an audit than a missing one.

What Is an IT Security Concept?

An IT security concept describes how an organization protects its information assets — that is, data, systems, applications, and processes — against identified risks. It is the document that bridges the gap between the overarching information security policy (which states: "We protect our information") and the concrete measures (which state: "This is how we do it").

In practice, many organizations use the terms security concept, security guideline, and security policy interchangeably. This leads to confusion, especially in audits. Therefore, a clear distinction is worthwhile.

Distinction: Guideline, Policy, Concept

Information security policy (overarching): The umbrella document of the ISMS. It formulates the principles of information security, the commitment of executive management, and the overarching objectives. The policy is short (typically two to five pages), strategic, and aimed at all employees. It rarely changes.

Topic-specific policies: Concretizations of the overarching policy for individual topics: password policy, access control policy, backup policy. They define binding rules for a specific area and are aimed at the affected employees or teams. Typical scope: three to eight pages per policy.

Security concept: The operational master document that describes the current state of security, summarizes the risk analysis, and documents the measures taken and planned. It refers to a defined scope (the entire organization or a subset) and is significantly more comprehensive than a single policy. Typical scope: 25 to 50 pages.

The key difference: the overarching policy says "What do we want to achieve?", the topical policies say "What are the rules?", and the security concept says "This is what our security posture looks like, and this is what we are doing to improve it."

Who Needs a Security Concept?

Every organization fundamentally benefits from a structured security concept. It becomes mandatory in several contexts:

  • ISO 27001: The standard requires a documented ISMS, the core of which is a security concept (even though the standard doesn't use this exact term).
  • NIS2: Article 21 requires risk analyses and security concepts as the first of ten minimum measures.
  • BSI IT-Grundschutz: The security concept is an explicit component of the methodology.
  • DSGVO (GDPR): Article 32 requires technical and organizational measures (TOMs) that can be consolidated in a security concept.
  • Industry-specific requirements: Critical infrastructure regulations, TISAX, BAIT, and other regulations require comparable documentation.

Even without a regulatory obligation, a security concept is a valuable tool. It forces you to systematically examine your own security posture and consciously plan measures rather than merely reacting to incidents.

BSI Recommendation: Security Concepts in IT-Grundschutz

The BSI describes a structured approach to creating security concepts in the IT-Grundschutz Compendium. Even if you are not pursuing BSI certification, this approach provides a proven framework you can use for orientation.

The BSI Approach in Brief

  1. Structural analysis: Identify the relevant information assets, business processes, and IT systems within the scope.
  2. Protection needs assessment: Evaluate the protection needs for each information asset regarding confidentiality, integrity, and availability.
  3. Modeling: Map the information assets to the appropriate BSI building blocks.
  4. IT-Grundschutz check: Review the implementation status of security requirements from the building blocks.
  5. Risk analysis: Conduct a supplementary risk analysis for assets with elevated protection needs.
  6. Consolidation and implementation: Consolidate, prioritize, and implement measures.

For SMEs, the full BSI approach is often too resource-intensive. However, the concepts and structure can be very effectively simplified and translated into a pragmatic security concept.

Structure and Outline: The Security Concept Step by Step

The following outline is intended as a template. It covers all essential aspects that an auditor expects and can be adapted to the size and complexity of your organization. For each section, you'll find an explanation of what belongs in it and why.

1. Introduction and Document History

What belongs here:

  • Purpose of the document
  • Target audience (who must read it)
  • Reference to the information security policy
  • Version table with date, version, change, and approver
  • Next scheduled review date

Why: The introduction establishes context. The auditor immediately sees whether the document is current and who approved it. The version table is not a formality. It proves that the document is regularly reviewed and updated as needed.

Scope: 1 to 2 pages

2. Scope

What belongs here:

  • Which organizational units, locations, and business processes are covered
  • Which IT systems, networks, and applications fall within scope
  • Explicit exclusions with justification
  • Reference to the ISMS scope (if an ISMS exists)

Why: The scope defines the boundaries of the security concept. Everything within these boundaries must be protected by measures. Everything outside must be excluded with justification. An imprecise scope is one of the most common audit findings.

Example scope for a 100-employee IT service provider:

The security concept covers the entire business operations of Muster GmbH at the main location Munich as well as the branch office Berlin. Included are all internal IT systems, the development and operating environments related to customer projects, the office infrastructure, employees' remote workstations, and the communication infrastructure. Excluded are customer-operated systems to which we have no administrative access, as well as employees' private IT equipment not used for business purposes.

Scope: 1 to 2 pages

3. Protection Objectives and Information Classification

What belongs here:

  • Definition of the three protection objectives: confidentiality, integrity, availability (CIA)
  • Optionally extended protection objectives: authenticity, accountability, non-repudiation
  • Classification scheme (e.g., public, internal, confidential, strictly confidential)
  • Examples for each classification level
  • Handling rules per level (storage, sharing, disposal)

Why: The protection objectives form the foundation of the risk assessment. The classification determines which protective measures are appropriate for which data. Without clear classification, the basis for differentiated protection measures is missing — and everything is either overprotected (expensive and impractical) or underprotected (risky).

Scope: 2 to 3 pages

4. Asset Overview and Protection Needs Assessment

What belongs here:

  • Overview of key information assets (critical business processes, data, IT systems, applications, networks)
  • Assignment of an owner (asset owner) to each asset
  • Protection needs per asset in the three dimensions (confidentiality, integrity, availability)
  • Rating scale (e.g., normal / high / very high per BSI methodology)
  • Justification for the classification

Why: You can only protect what you know. The asset overview is the map of your security concept. The protection needs assessment determines how much protection each asset requires and prevents both over- and underprotection.

Tip: You don't need to list every individual system here. Group similar systems together (e.g., "administration workstations") and assess them as a group. Individual assessments are only necessary where the protection needs of individual systems differ significantly from the rest of the group.

Scope: 3 to 6 pages (depending on the number of assets)

5. Risk Analysis

What belongs here:

  • Description of the risk assessment methodology (probability and impact, rating scale, risk matrix)
  • Identified risks with description, affected assets, probability, impact, and resulting risk score
  • Risk acceptance criteria: which risk level is acceptable, what must be treated?
  • Connection to the protection needs assessment: risks for assets with high or very high protection needs require deeper analysis.

Why: The risk analysis is the heart of the security concept. It provides the factual justification for every measure. Without a risk analysis, protective measures are based on gut feeling rather than systematic assessment — and in audits, the traceability is missing.

Presentation format: A risk matrix (heat map) with probability on one axis and impact on the other is the most common format. Supplement it with a tabular listing of individual risks with risk ID, description, affected assets, assessment, and treatment decision.

Scope: 4 to 8 pages

6. Technical Measures

What belongs here:

  • Network security: firewall architecture, network segmentation, IDS/IPS, VPN
  • Endpoint protection: antivirus, disk encryption, patch management, hardening
  • Server security: OS hardening, access restrictions, logging
  • Application security: secure configuration, update management, web application protection
  • Encryption: transport encryption (TLS), encryption at rest, email encryption
  • Authentication: password policy, multi-factor authentication, SSO
  • Monitoring and logging: what is logged, for how long, who reviews it
  • Backup and recovery: backup strategy, retention periods, restore tests

Why: The technical measures form the operational core of the security concept. They describe which protective mechanisms are concretely implemented or planned. Each measure should be traceable to at least one risk from the risk analysis.

Important: Describe the measures at an abstraction level appropriate for the security concept. Detailed technical configurations (firewall rule sets, GPO settings) belong in operating procedures or technical manuals, not in the security concept. The concept describes the "what and why," not the "how in detail."

Scope: 5 to 10 pages

7. Organizational Measures

What belongs here:

  • Security organization: CISO, roles, and responsibilities
  • Personnel security: background checks at hiring, non-disclosure agreements, onboarding/offboarding
  • Training and awareness: training program, frequency, target groups
  • Document control: versioning, approval, review cycles
  • Access control: authorization concept, recertification, least privilege
  • Supplier management: assessment, contractual requirements, monitoring
  • Physical security: access control, visitor policies, clean desk policy
  • Compliance: regulatory requirements (GDPR, NIS2, industry-specific)

Why: Technology alone does not protect. Organizational measures ensure that technical measures operate within a functioning framework. An authorization concept is of little use if there is no process to ensure access is revoked when an employee leaves.

Scope: 4 to 8 pages

8. Emergency Preparedness and Incident Response

What belongs here:

  • Reference to the detailed incident response plan (if it exists as a separate document)
  • Summary of the approach to security incidents: detection, assessment, containment, eradication, recovery, lessons learned
  • Escalation levels and communication channels
  • Reporting obligations (NIS2: 24h/72h/1 month; GDPR: 72h for data breaches)
  • Reference to the business continuity plan and recovery plan
  • Contact list: internal contacts, CERT, BSI, external service providers, attorney

Why: A security concept that does not describe what happens during an incident is incomplete. Emergency preparedness connects the preventive security concept with the reactive incident response. In an emergency, everyone must know what to do without first having to read the entire security concept.

Scope: 2 to 4 pages (summary with references to detail documents)

9. Responsibilities and Governance

What belongs here:

  • RACI matrix or comparable presentation: who is Responsible, Accountable, Consulted, and Informed for each area of the security concept
  • Reporting lines: who reports to whom, at what cadence
  • Committees: security committee, management review, crisis team if applicable
  • Escalation paths for conflicts (e.g., when a business unit rejects a measure)

Why: Clear responsibilities prevent tasks from falling into gaps. The RACI matrix is a proven tool for seeing at a glance who is responsible for what — and it is one of the first things an auditor will request.

Scope: 2 to 3 pages

10. Action Plan and Implementation Status

What belongs here:

  • Tabular overview of all measures from sections 6 and 7
  • Per measure: ID, description, assigned risk, responsible person, deadline, status (implemented / in progress / planned / open)
  • Prioritization (critical, high, medium, low)
  • Budget and resource requirements (where known)

Why: The action plan transforms the security concept from a descriptive document into a management tool. Without it, the concept remains theory. With it, it becomes the roadmap for implementation — and the auditor can track progress.

Tip: Link the action plan to the risk register. Every measure should reference one or more risks, and every risk with a rating above the acceptable level should have at least one assigned measure.

Scope: 2 to 4 pages (table)

11. Review Cycle and Updates

What belongs here:

  • Scheduled review: how often the security concept is reviewed (recommendation: at least annually)
  • Event-triggered review: which events trigger an unscheduled review (e.g., after a security incident, upon significant changes to the IT landscape, new regulatory requirements, after an audit)
  • Person responsible for the review
  • Approval process for updated versions

Why: An outdated security concept is worse than none at all because it conveys a false sense of security. The defined review cycle ensures the document keeps pace with reality.

Scope: 1 page

Sample Outline at a Glance

Here is the complete outline in summary as a reference:

IT Security Concept of Muster GmbH

1.  Introduction and Document History
    1.1 Purpose and Target Audience
    1.2 Reference to Information Security Policy
    1.3 Version Table

2.  Scope
    2.1 Included Areas
    2.2 Exclusions and Justifications

3.  Protection Objectives and Information Classification
    3.1 Protection Objectives (CIA)
    3.2 Classification Scheme
    3.3 Handling Rules

4.  Asset Overview and Protection Needs Assessment
    4.1 Critical Business Processes
    4.2 Information Assets and IT Systems
    4.3 Protection Needs Assessment

5.  Risk Analysis
    5.1 Risk Assessment Methodology
    5.2 Identified Risks
    5.3 Risk Matrix
    5.4 Risk Acceptance Criteria

6.  Technical Measures
    6.1 Network Security
    6.2 Endpoint Protection
    6.3 Server Security
    6.4 Encryption
    6.5 Authentication and Access Control
    6.6 Monitoring and Logging
    6.7 Backup and Recovery

7.  Organizational Measures
    7.1 Security Organization
    7.2 Personnel Security
    7.3 Training and Awareness
    7.4 Supplier Management
    7.5 Physical Security
    7.6 Compliance

8.  Emergency Preparedness and Incident Response
    8.1 Approach to Security Incidents
    8.2 Escalation and Communication
    8.3 Reporting Obligations
    8.4 Business Continuity (Reference)

9.  Responsibilities and Governance
    9.1 RACI Matrix
    9.2 Reporting Lines and Committees
    9.3 Escalation Paths

10. Action Plan and Implementation Status

11. Review Cycle and Updates
    11.1 Scheduled Review
    11.2 Event-Triggered Review
    11.3 Approval Process

Appendices:
A.  Glossary
B.  Referenced Documents
C.  Emergency Contact List

Scope and Level of Detail: What Is Appropriate?

The most common question when creating a security concept is: how detailed does it need to be? The answer depends on several factors.

Organization Size as a Guide

Organization Size Recommended Scope Level of Detail
10 to 50 employees 15 to 25 pages Compact, focused on the biggest risks and most important measures
50 to 200 employees 25 to 50 pages Complete outline as described above
200 to 500 employees 40 to 80 pages More detailed asset overview, potentially area-specific sub-concepts
500+ employees 60 to 120+ pages Comprehensive concept with sub-concepts for areas or locations

These are guideline figures. A 100-employee organization with a simple IT landscape (one location, standard office IT, no in-house development) can manage with 25 pages. The same organization with a complex IT landscape (multiple locations, cloud and on-premises, in-house software development, international clients) needs closer to 45 to 50 pages.

Common Mistakes in Level of Detail

Too little detail: The security concept lists only headings without substantive content. "Network security is ensured by a firewall" is not sufficient. What firewall architecture? What segmentation? What rule philosophy? The auditor wants to see that you've given it thought.

Too much detail: The security concept contains firewall rules, IP addresses, configuration parameters. This makes it a security risk (if it falls into the wrong hands) and a maintenance nightmare (every configuration change requires updating the concept). Technical details belong in operating manuals and procedures, not in the security concept.

The right middle ground: In the security concept, describe the principle and architecture, not the configuration. Instead of "Firewall rule: permit tcp 10.0.1.0/24 10.0.2.0/24 eq 443," write: "The production network is separated from the office network by a firewall. Traffic between zones is restricted to the protocols and ports necessary for business operations. Rules are reviewed quarterly."

Modular Structure

As complexity grows, it can make sense to structure the security concept modularly. The overarching security concept contains sections 1 to 5 and 8 to 11 in full. Sections 6 and 7 are outsourced to sub-concepts:

  • Sub-concept: Network Security
  • Sub-concept: Cloud Security
  • Sub-concept: Berlin Location (Physical Security)
  • Sub-concept: Software Development

Each sub-concept references the overarching security concept and is independently versioned and approved. The advantage: changes in one area don't require updating the entire document. The disadvantage: a document hierarchy is created that must be maintained.

Updates: When and How

A security concept is not a static document. It must keep pace with the development of the organization, the threat landscape, and the IT landscape.

Regular Review

Plan at least an annual review of the entire security concept. The best timing is after the management review, as findings from the review can then be directly incorporated. The review does not necessarily have to result in changes. It is sufficient to document that the review took place and the concept remains current.

Event-Triggered Updates

The following events should trigger an unscheduled review and potential update:

  • Security incident: Every relevant incident can reveal weaknesses in the security concept that need to be addressed.
  • Significant IT changes: Cloud migration, introduction of new business applications, location change, acquisition of another company.
  • New regulatory requirements: Changes to NIS2, GDPR, or industry-specific regulations.
  • Audit findings: When an internal or external audit identifies deviations affecting the security concept.
  • Organizational changes: Restructuring, new business areas, merger, or spin-off.

Change Management

Changes to the security concept follow the document control procedure:

  1. Draft the change by the CISO or the responsible subject matter expert
  2. Review by affected stakeholders
  3. Approval by the CISO (for significant changes, by executive management)
  4. Update the version table
  5. Communicate changes to affected staff
  6. Archive the previous version

From Template to Finished Concept

You now have a complete outline and know what belongs in each section. The next step is the actual creation. Here is a pragmatic approach that has proven effective in mid-market companies.

Step 1: Scope and Assets (Weeks 1 to 2)

Start with the scope and asset overview. Both sections lay the foundation. Talk to business departments to get a realistic picture of the IT landscape and business processes. A first asset overview doesn't need to be perfect — it needs to be complete enough to support the risk analysis.

Step 2: Risk Analysis (Weeks 3 to 5)

Conduct the risk assessment based on the identified assets and their protection needs. Involve the IT department and business departments. Risks assessed only from an IT perspective regularly miss the business relevance.

Step 3: Document Measures (Weeks 5 to 8)

Document existing technical and organizational measures. Identify gaps between the current state and the target state (derived from the risk analysis). In ISMS Lite, you can link measures directly to identified risks and track implementation status per control. Create the action plan for the gaps.

Step 4: Consolidation and Review (Weeks 8 to 10)

Bring all sections together, add the framework chapters (introduction, protection objectives, responsibilities, review cycle), and have the complete document reviewed by relevant stakeholders.

Step 5: Approval and Communication (Weeks 10 to 12)

Have the security concept approved by executive management and communicate it to the affected parties. The security concept itself doesn't need to be shared with all employees, but the policies and behavioral rules derived from it do.

Twelve weeks for an initial security concept is realistic if you can dedicate time to it. If the security concept is created alongside daily operations, plan for 16 to 20 weeks instead. The first concept is always the most labor-intensive. The annual update goes significantly faster because you only need to incorporate changes.

The Security Concept as a Living Document

A security concept that sits in a drawer and is dutifully pulled out once a year misses its purpose. It should be the reference document consulted for every security-relevant decision. When a new system is introduced, refer to the security concept: does the measure match the protection needs? When an incident occurs, check the security concept: was this risk identified? Were the measures appropriate?

Therefore, keep the concept as lean and practical as possible. Every page that adds no value is a page nobody reads. And a document nobody reads cannot protect anyone.

Further Reading

Start with the scope and asset overview. Once you know what you need to protect, the risk analysis and measures follow almost naturally. The security concept grows with your organization and your ISMS. It doesn't have to be perfect on the first pass — but it must exist, be current, and actually be used.

From Concept to Implementation

In ISMS Lite you capture risks, link them to concrete measures, and track implementation status per control. Turn your security concept into a living management tool instead of a document gathering dust.

Install Now