msolarczek/craftvia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Basis: Certvia dev@a48c5fb als Fundament für Craftvia
CI / build-and-check (push) Canceled after 0s
Details
CI / audit (push) Canceled after 0s
Details
CI / sbom (push) Canceled after 0s
Details

Browse Source 
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
msolarczek
2026-09-14 11:05:39 +02:00
co-authored by Claude Opus 5
commit c8e6f30a27
720 changed files with 140143 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
seed/isms-vorlagenpaket-v2-en/Nachweisregister_zentral.md
+47
View File
@@ -0,0 +1,47 @@
# Central Evidence Register – ISMS {{ORG_NAME}}
| Document information | Value |
|-----------------------|------|
| Document type | Evidence register (applies to all policies) |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
| Responsible | {{ROLE_ISB}} |
## Purpose
This document consolidates **all evidence** for the ISMS in one place. The individual policies do not contain evidence lists but refer to this ({{LINK:NACHWEISREGISTER}}). Registers with ongoing records (asset inventory, risk register, supplier/NDA register, awareness evidence, record of processing activities) are maintained in **{{TOOL_NAME}}**; this register refers to them.
The fine-grained mapping of evidence ↔ individual MUST/SHOULD requirement is done via `mapping.json` (hidden anchors `REQ`/`IMPL`) and is not visible in reading mode. From this, the tool generates an evidence link per requirement.
## Evidence overview
| # | Policy | Evidence | Source | Responsible | Cycle |
|---|-----------|----------|--------|----------------|--------|
| 1 | {{LINK:L00}} | Approved, versioned IS policy incl. communication record | Doc | {{ROLE_MANAGEMENT}} | {{REVIEW_CYCLE}} |
| 2 | {{LINK:R01}} | ISMS scope, role/responsibility matrix, management review | Tool/Doc | {{ROLE_ISB}} | annually |
| 3 | {{LINK:R02}} | Asset inventory & classification matrix; list of approved hardware/software | Tool | {{ROLE_IT_LEAD}} | ongoing |
| 4 | {{LINK:R03}} | Risk register & treatment plan; internal/independent review reports | Tool/Doc | {{ROLE_ISB}} | ≤ annually |
| 5 | {{LINK:R04}} | Incident records; crisis/emergency plan; recovery tests | Tool/Doc | {{ROLE_ISB}} | ongoing |
| 6 | {{LINK:R05}} | Confidentiality obligations; training/awareness evidence | Tool | {{ROLE_HR_LEAD}} | upon joining / annually |
| 7 | {{LINK:R06}} | Rule & approvals for mobile working / mobile devices | Doc/Tool | {{ROLE_ISB}} | ongoing |
| 8 | {{LINK:R07}} | Access concept, zone plan, access logs | Doc | {{ROLE_IT_LEAD}} | ongoing |
| 9 | {{LINK:R08}} | Authorisation concept & recertification evidence | Tool | {{ROLE_IT_LEAD}} | ≤ annually |
| 10 | {{LINK:R09}} | Cryptography concept, key/certificate management | Doc | {{ROLE_IT_LEAD}} | ongoing |
| 11 | {{LINK:R10}} | Change/patch/vulnerability reports, malware status, logging, backup/recovery tests | Tool/rec. | {{ROLE_IT_LEAD}} | ongoing |
| 12 | {{LINK:R11}} | Security requirements procurement/development; deletion evidence | Doc/rec. | {{ROLE_IT_LEAD}} | ongoing |
| 13 | {{LINK:R12}} | Approval list for cloud/AI services, segregation/data-flow evidence | Tool/Doc | {{ROLE_ISB}} | ongoing |
| 14 | {{LINK:R13}} | Supplier register, NDAs, delineation of responsibilities | Tool | {{ROLE_ISB}} | ongoing |
| 15 | {{LINK:R14}} | Compliance/legal register; record of processing activities | Tool | {{ROLE_DPO}} | ≤ annually |
| 16 | {{LINK:VA-22}} | Metrics sheet with targets, owners and measured values per period | Tool | {{ROLE_ISB}} | {{MGMT_REVIEW_CYCLE}} |
| 17 | {{LINK:VA-22}} | Management review minutes with inputs, decisions and due dates | Tool/Doc | {{ROLE_MANAGEMENT}} | {{MGMT_REVIEW_CYCLE}} |
| 18 | {{LINK:VA-21}} | Action register: nonconformities, root cause analysis, effectiveness review | Tool | {{ROLE_ISB}} | ongoing |
| 19 | {{LINK:R03}} | Statement of Applicability with justification, origin and implementation status | Tool/Doc | {{ROLE_ISB}} | {{RISK_REVIEW_CYCLE}} |
| 20 | {{LINK:L00}} | Read receipts of staff per approved policy version | Tool | {{ROLE_ISB}} | {{POLICY_REVIEW_CYCLE}} |
> **Wizard note:** Rows with source `Tool` are not generated as a document but link to the record in {{TOOL_NAME}}. Conditional evidence is shown/hidden based on the feature flags (e.g. row 13 only with flag `FLAG_CLOUD_USED` / `FLAG_AI_USED`, row 10 only with flag `FLAG_CRYPTO_PKI`).
## Related documents
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Information security policy: {{LINK:L00}}
seed/isms-vorlagenpaket-v2-en/Statement-of-Applicability-ISO.md
+135
View File
@@ -0,0 +1,135 @@
# Statement of Applicability
| Document information | Value |
|-----------------------|------|
| Document type | Statement of Applicability |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## Purpose
For each control of Annex A of ISO/IEC 27001:2022 this statement records whether it is applicable, why it was included or excluded, what it derives from and how far it is implemented (ISO/IEC 27001:2022, 6.1.3 d). It is updated with every risk assessment ({{RISK_REVIEW_CYCLE}}) and approved by {{ROLE_MANAGEMENT}}. The procedure is set out in {{LINK:R03}}.
**Columns:** *Applicable* = yes/no · *Justification* = reason for inclusion or exclusion · *Origin* = risk ID, legal or contractual requirement · *Status* = implemented / partial / planned · *Evidence* = reference into the evidence register ({{LINK:NACHWEISREGISTER}}).
## A.5 Organisational controls (37 controls)
| Control | Title | Applicable | Justification | Origin | Status | Policy | Procedure | Evidence |
|---|---|:--:|---|---|---|---|---|---|
| A.5.1 | Policies for information security | yes | Determined as necessary by the risk treatment. | | | {{LINK:L00}} | - | |
| A.5.2 | Information security roles and responsibilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | - | |
| A.5.3 | Segregation of duties | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | - | |
| A.5.4 | Management responsibilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | - | |
| A.5.5 | Contact with authorities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | - | |
| A.5.6 | Contact with special interest groups | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | - | |
| A.5.7 | Threat intelligence | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.5.8 | Information security in project management | yes | Determined as necessary by the risk treatment. | | | {{LINK:R01}} | VA-19 | |
| A.5.9 | Inventory of information and other associated assets | yes | Determined as necessary by the risk treatment. | | | {{LINK:R02}} | VA-08 | |
| A.5.10 | Acceptable use of information and other associated assets | yes | Determined as necessary by the risk treatment. | | | {{LINK:R02}} | VA-08 | |
| A.5.11 | Return of assets | yes | Determined as necessary by the risk treatment. | | | {{LINK:R11}} | VA-08 | |
| A.5.12 | Classification of information | yes | Determined as necessary by the risk treatment. | | | {{LINK:R02}} | VA-08 | |
| A.5.13 | Labelling of information | yes | Determined as necessary by the risk treatment. | | | {{LINK:R02}} | VA-08 | |
| A.5.14 | Information transfer | yes | Determined as necessary by the risk treatment. | | | {{LINK:R09}} | - | |
| A.5.15 | Access control | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.5.16 | Identity management | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.5.17 | Authentication information | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.5.18 | Access rights | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.5.19 | Information security in supplier relationships | yes | Determined as necessary by the risk treatment. | | | {{LINK:R13}} | VA-10 | |
| A.5.20 | Addressing information security within supplier agreements | yes | Determined as necessary by the risk treatment. | | | {{LINK:R13}} | VA-10 | |
| A.5.21 | Managing information security in the ICT supply chain | yes | Determined as necessary by the risk treatment. | | | {{LINK:R13}} | VA-10 | |
| A.5.22 | Monitoring, review and change management of supplier services | yes | Determined as necessary by the risk treatment. | | | {{LINK:R13}} | VA-10 | |
| A.5.23 | Information security for use of cloud services | {{#if FLAG_CLOUD_USED}}yes{{/if}}{{#unless FLAG_CLOUD_USED}}no{{/unless}} | {{#if FLAG_CLOUD_USED}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_CLOUD_USED}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R12}} | VA-11 | |
| A.5.24 | Information security incident management planning and preparation | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
| A.5.25 | Assessment and decision on information security events | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
| A.5.26 | Response to information security incidents | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
| A.5.27 | Learning from information security incidents | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
| A.5.28 | Collection of evidence | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
| A.5.29 | Information security during disruption | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-02 | |
| A.5.30 | ICT readiness for business continuity | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-02 | |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | yes | Determined as necessary by the risk treatment. | | | {{LINK:R14}} | VA-18 | |
| A.5.32 | Intellectual property rights | yes | Determined as necessary by the risk treatment. | | | {{LINK:R14}} | VA-18 | |
| A.5.33 | Protection of records | yes | Determined as necessary by the risk treatment. | | | {{LINK:R14}} | VA-18 | |
| A.5.34 | Privacy and protection of PII | {{#if FLAG_PERSONAL_DATA}}yes{{/if}}{{#unless FLAG_PERSONAL_DATA}}no{{/unless}} | {{#if FLAG_PERSONAL_DATA}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_PERSONAL_DATA}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R14}} | VA-18 | |
| A.5.35 | Independent review of information security | yes | Determined as necessary by the risk treatment. | | | {{LINK:R03}} | VA-15 | |
| A.5.36 | Compliance with policies, rules and standards for information security | yes | Determined as necessary by the risk treatment. | | | {{LINK:R03}} | VA-15 | |
| A.5.37 | Documented operating procedures | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
## A.6 People controls (8 controls)
| Control | Title | Applicable | Justification | Origin | Status | Policy | Procedure | Evidence |
|---|---|:--:|---|---|---|---|---|---|
| A.6.1 | Screening | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | VA-14 | |
| A.6.2 | Terms and conditions of employment | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | VA-14 | |
| A.6.3 | Information security awareness, education and training | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | VA-12 | |
| A.6.4 | Disciplinary process | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | - | |
| A.6.5 | Responsibilities after termination or change of employment | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | VA-14 | |
| A.6.6 | Confidentiality or non-disclosure agreements | yes | Determined as necessary by the risk treatment. | | | {{LINK:R05}} | VA-14 | |
| A.6.7 | Remote working | {{#if FLAG_MOBILE_WORK}}yes{{/if}}{{#unless FLAG_MOBILE_WORK}}no{{/unless}} | {{#if FLAG_MOBILE_WORK}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_MOBILE_WORK}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R06}} | - | |
| A.6.8 | Information security event reporting | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-01 | |
## A.7 Physical controls (14 controls)
| Control | Title | Applicable | Justification | Origin | Status | Policy | Procedure | Evidence |
|---|---|:--:|---|---|---|---|---|---|
| A.7.1 | Physical security perimeters | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.2 | Physical entry | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.3 | Securing offices, rooms and facilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.4 | Physical security monitoring | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.5 | Protecting against physical and environmental threats | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.6 | Working in secure areas | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.7 | Clear desk and clear screen | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.8 | Equipment siting and protection | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.9 | Security of assets off-premises | {{#if FLAG_MOBILE_DEVICES}}yes{{/if}}{{#unless FLAG_MOBILE_DEVICES}}no{{/unless}} | {{#if FLAG_MOBILE_DEVICES}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_MOBILE_DEVICES}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R06}} | - | |
| A.7.10 | Storage media | yes | Determined as necessary by the risk treatment. | | | {{LINK:R06}} | VA-08 | |
| A.7.11 | Supporting utilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.12 | Cabling security | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-17 | |
| A.7.13 | Equipment maintenance | yes | Determined as necessary by the risk treatment. | | | {{LINK:R07}} | VA-04 | |
| A.7.14 | Secure disposal or re-use of equipment | yes | Determined as necessary by the risk treatment. | | | {{LINK:R11}} | VA-08 | |
## A.8 Technological controls (34 controls)
| Control | Title | Applicable | Justification | Origin | Status | Policy | Procedure | Evidence |
|---|---|:--:|---|---|---|---|---|---|
| A.8.1 | User endpoint devices | yes | Determined as necessary by the risk treatment. | | | {{LINK:R06}} | - | |
| A.8.2 | Privileged access rights | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.8.3 | Information access restriction | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.8.4 | Access to source code | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.5 | Secure authentication | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.8.6 | Capacity management | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.7 | Protection against malware | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.8 | Management of technical vulnerabilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-06 | |
| A.8.9 | Configuration management | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-04 | |
| A.8.10 | Information deletion | yes | Determined as necessary by the risk treatment. | | | {{LINK:R11}} | VA-08 | |
| A.8.11 | Data masking | {{#if FLAG_PERSONAL_DATA}}yes{{/if}}{{#unless FLAG_PERSONAL_DATA}}no{{/unless}} | {{#if FLAG_PERSONAL_DATA}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_PERSONAL_DATA}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R02}} | - | |
| A.8.12 | Data leakage prevention | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.13 | Information backup | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-05 | |
| A.8.14 | Redundancy of information processing facilities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R04}} | VA-02 | |
| A.8.15 | Logging | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-13 | |
| A.8.16 | Monitoring activities | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-13 | |
| A.8.17 | Clock synchronisation | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-13 | |
| A.8.18 | Use of privileged utility programs | yes | Determined as necessary by the risk treatment. | | | {{LINK:R08}} | VA-03 | |
| A.8.19 | Installation of software on operational systems | yes | Determined as necessary by the risk treatment. | | | {{LINK:R02}} | VA-04 | |
| A.8.20 | Networks security | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.21 | Security of network services | yes | Determined as necessary by the risk treatment. | | | {{LINK:R11}} | - | |
| A.8.22 | Segregation of networks | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.23 | Web filtering | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | - | |
| A.8.24 | Use of cryptography | yes | Determined as necessary by the risk treatment. | | | {{LINK:R09}} | VA-07 | |
| A.8.25 | Secure development life cycle | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.26 | Application security requirements | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.27 | Secure system architecture and engineering principles | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.28 | Secure coding | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.29 | Security testing in development and acceptance | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.30 | Outsourced development | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.31 | Separation of development, test and production environments | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R10}} | VA-16 | |
| A.8.32 | Change management | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-04 | |
| A.8.33 | Test information | {{#if FLAG_DEV_INHOUSE}}yes{{/if}}{{#unless FLAG_DEV_INHOUSE}}no{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Determined as necessary by the risk treatment.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Not applicable - enter justification.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.34 | Protection of information systems during audit testing | yes | Determined as necessary by the risk treatment. | | | {{LINK:R10}} | VA-15 | |
## Management system requirements (clauses 4-10)
The requirements of clauses 4 to 10 are not subject to the Statement of Applicability; they apply directly. Their allocation to the policies is held in `mapping-iso.json`.
seed/isms-vorlagenpaket-v2-en/Technische-Sicherheits-Baseline.md
+113
View File
@@ -0,0 +1,113 @@
# Technical Security Baseline
| Document information | Value |
|-----------------------|------|
| Document type | Requirements document (baseline) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## Purpose
This document defines the **concrete technical minimum parameters** of information security. It is the central point of maintenance for all measurable values (password lengths, deadlines, procedures). For exact values, the policies R01–R14 refer to the **baseline IDs** assigned here (e.g. `BL-IAM-01`) and repeat the key statement concretely in the respective implementation text.
Changes to parameters are made exclusively here and are approved by {{ROLE_ISB}}. The values are stored as adjustable defaults (variables); they correspond to the state of the art (guided, among others, by BSI IT-Grundschutz and current NIST recommendations).
## 1. Identity and access management
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-IAM-01 | Password requirements | Minimum length {{PW_MIN_LENGTH}} characters; {{PW_COMPLEXITY}}; check against known/compromised passwords; {{PW_ROTATION}} |
| BL-IAM-02 | Multi-factor authentication (MFA) | Mandatory for {{MFA_SCOPE}} |
| BL-IAM-03 | Session management | Automatic lock upon inactivity: {{SESSION_TIMEOUT}} |
| BL-IAM-04 | Account lockout | {{ACCOUNT_LOCKOUT}} |
| BL-IAM-05 | Recertification of authorisations | {{RECERT_FREQ}}; privileged rights additionally on an ad-hoc basis |
| BL-IAM-06 | Privileged/technical accounts | Separate management, individual assignment, enhanced logging; management via the central directory ({{TOOL_IAM}}) |
| BL-IAM-07 | IAM documentation location | Requests/approvals/blockings in {{TOOL_TICKET}}; account management in the central directory ({{TOOL_IAM}}) |
## 2. Cryptography and transmission
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-CRY-01 | Transport encryption | At least {{TLS_MIN}}; insecure protocols deactivated |
| BL-CRY-02 | Permissible algorithms/key lengths | {{CRYPTO_ALGO}} |
| BL-CRY-03 | Data media encryption | Full encryption of mobile devices and data media (AES-256) |
| BL-CRY-04 | Email/file exchange | Encryption of content requiring protection; secure exchange paths prescribed |
| BL-CRY-05 | Key management | Defined lifecycle (generation, distribution, storage, revocation, destruction){{#if FLAG_CRYPTO_PKI}}; PKI/certificate management established{{/if}} |
## 3. Operational security
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-OPS-01 | Patch SLA | Critical: {{PATCH_SLA_CRIT}}; high: {{PATCH_SLA_HIGH}}; standard: {{PATCH_SLA_STD}} |
| BL-OPS-02 | Vulnerability scanning | {{VULN_SCAN_FREQ}}; tracking in {{TOOL_TICKET}} |
| BL-OPS-03 | Malware protection | {{TECH_MALWARE}} on all endpoints/servers; signature/engine update {{MALWARE_UPDATE}} |
| BL-OPS-04 | Logging & retention | Central logging ({{TECH_SIEM}}); retention {{LOG_RETENTION}}; tamper-protected |
| BL-OPS-05 | Data backup | Scheme {{BACKUP_SCHEME}} via {{TECH_BACKUP}}; retention {{BACKUP_RETENTION}} |
| BL-OPS-06 | Recovery tests | {{BACKUP_TEST_FREQ}}; result documented |
| BL-OPS-07 | System hardening | Hardening requirements (e.g. CIS benchmarks) for standard systems |
| BL-OPS-08 | Technical review / penetration test | {{PENTEST_FREQ}} or risk-oriented |
| BL-OPS-09 | Change management | Request/assessment/test/approval/documentation in {{TOOL_TICKET}} |
{{#if FLAG_FW_ISO27001}}
| BL-OPS-10 | Time synchronisation | System clocks of all logging systems synchronised to {{NTP_SOURCES}}; deviations are monitored |
| BL-OPS-11 | Capacity management | Utilisation (compute, memory, bandwidth, licences) monitored {{CAPACITY_REVIEW_FREQ}}; thresholds raise an alert |
| BL-OPS-12 | Protection against data leakage | Measures against unauthorised outflow of protected information for {{DLP_SCOPE}} |
{{/if}}
## 4. Network security
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-NET-01 | Segmentation | Separation according to protection need; {{#if FLAG_OT_USED}}production/OT networks separated and specially secured; {{/if}}guest/external networks isolated |
| BL-NET-02 | Perimeter & remote access | Firewall with default deny; remote access only via {{TECH_VPN}} with MFA (BL-IAM-02) |
{{#if FLAG_FW_ISO27001}}
| BL-NET-03 | Web filtering | Access to external web content filtered (categories, known malicious sites); exceptions documented and time-limited |
{{/if}}
## 5. Endpoint and mobile use
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-EP-01 | Device management | Management via {{TECH_MDM}}; only approved devices |
| BL-EP-02 | Device encryption/remote wipe | Full encryption (BL-CRY-03); blocking/wiping upon loss via {{TECH_MDM}} |
| BL-EP-03 | Removable media | Only encrypted and approved; use controlled |
## 6. Physical security
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-PHY-01 | Security zones | Defined zones; access on a needs-oriented basis, documented, revoked when no longer needed |
| BL-PHY-02 | Access logging | Logging for areas requiring protection; visitors registered and escorted |
{{#if FLAG_FW_ISO27001}}
| BL-PHY-03 | Environmental protection and utilities | Early fire detection, protection against water, temperature/humidity monitoring in technical rooms; uninterruptible power for critical systems, tested regularly |
| BL-PHY-04 | Clear desk and screen lock | Protected documents and media locked away when unattended; automatic screen lock after {{SESSION_TIMEOUT}} |
{{/if}}
## 7. Personnel and suppliers
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-HR-01 | Awareness/training | Upon joining and thereafter at least {{REVIEW_CYCLE}}; evidence in {{TOOL_NAME}} |
| BL-SUP-01 | Supplier risk classes | Classification according to protection need and access; verification of compliance (evidence/TISAX) |
| BL-DEL-01 | Secure deletion | Deletion/destruction appropriate to the protection need (e.g. according to recognised standards); deletion evidence |
## 8. Governance and projects
| ID | Parameter | Requirement |
|----|-----------|---------|
| BL-GOV-01 | Audit/review cycle | Internal review {{REVIEW_CYCLE}}; independent review/assessment at least every 3 years or after fundamental changes |
| BL-PROJ-01 | Project classification criteria | Documented catalogue of criteria for the IS classification of projects (triggers/thresholds for ISO involvement) |
{{#if FLAG_FW_ISO27001}}
| BL-GOV-02 | Management review | Top management reviews the ISMS {{MGMT_REVIEW_CYCLE}} against a fixed agenda; decisions with owner and due date |
| BL-GOV-03 | Document control | Review cycle of the policy and thematic policies {{POLICY_REVIEW_CYCLE}}; four-eyes approval; retention of superseded versions {{RECORDS_RETENTION}} |
{{/if}}
## Change history
| Version | Date | Author | Change |
|---------|-------|-------|----------|
| {{DOC_VERSION}} | {{DOC_DATE}} | {{ROLE_IT_LEAD}} | Creation |
seed/isms-vorlagenpaket-v2-en/mapping-iso.json
+2219
View File
File diff suppressed because it is too large Load Diff
seed/isms-vorlagenpaket-v2-en/mapping.json
+5351
View File
File diff suppressed because it is too large Load Diff
seed/isms-vorlagenpaket-v2-en/richtlinien/D01_Datenschutz.md
+49
View File
@@ -0,0 +1,49 @@
# Policy Data Protection
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_DPO}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the protection of personal data (assessment objective data protection, VDA ISA chapter 9). It elaborates the information security policy ({{LINK:L00}}) and complements the policy Compliance and Data Protection ({{LINK:R14}}).
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}), insofar as personal data is processed.
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA, chapter 9) and **Implementation at {{ORG_NAME}}**.
{{#if FLAG_PERSONAL_DATA}}
### 3.1 Data protection organisation (ISA 9.1.1)
**Requirement**
<!-- REQ 9.1.1-M1 -->
- **[MUST]** Responsibilities for data protection are appointed and the data protection organisation is documented.
**Implementation at {{ORG_NAME}}**
The role {{ROLE_DPO}} is appointed and integrated into the ISMS organisation. Tasks, reporting paths and escalation are documented.
### 3.2 Lawfulness and record of processing activities (ISA 9.2.1)
**Requirement**
<!-- REQ 9.2.1-M1 -->
- **[MUST]** Processing of personal data is lawful, purpose-bound and recorded in a record of processing activities.
**Implementation at {{ORG_NAME}}**
A record of processing activities is maintained and updated regularly. For each processing activity, the legal basis, purpose and deletion periods are documented.
{{/if}}
seed/isms-vorlagenpaket-v2-en/richtlinien/L00_Informationssicherheitsleitlinie.md
+175
View File
@@ -0,0 +1,175 @@
# Information Security Policy
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
<!-- REQ 1.1.1-M1 -->
This information security policy describes the fundamental requirements, objectives and responsibilities of {{ORG_NAME}} for protecting information, IT systems, business processes and supporting assets. The information security requirements are defined, documented and aligned with the objectives of {{ORG_NAME}}.
The objective is to ensure an appropriate level of information security and to meet the requirements of VDA ISA 2027 in the area of information security.
## 2. Scope
This policy applies to the defined ISMS scope:
{{ISMS_SCOPE_DESCRIPTION}}
It applies to:
- all employees within the scope,
- managers,
- external service providers, insofar as they have access to the organisation's information, systems or processes,
- relevant IT systems, information, applications, sites and business processes within the ISMS scope.
## 3. Information security objectives
<!-- REQ 1.1.1-M3 -->
The policy states the objectives and the importance of information security. Through the ISMS, the organisation pursues in particular the following objectives:
- protection of confidential information against unauthorised access,
- ensuring the integrity of information and systems,
- ensuring the availability of business-critical information, systems and services,
- compliance with legal, regulatory and contractual requirements,
- appropriate protection of customer information, personal data, trade secrets and other information requiring protection,
- structured identification, assessment and treatment of information security risks,
- continual improvement of information security.
## 4. Information security principles
Information security is based on the following principles:
### 4.1 Risk orientation
Information security measures are planned, implemented, reviewed and improved in a risk-oriented manner. Risks are assessed and tracked in the ISMS tool in use ({{TOOL_NAME}}) (see {{LINK:R03}}).
### 4.2 Appropriateness
Protective measures must be appropriate to the protection needs of the information, systems and processes. Confidentiality, integrity and availability are taken into account.
### 4.3 Responsibility
Information security is a shared responsibility of all employees. {{ROLE_MANAGEMENT}} holds overall responsibility for the ISMS.
### 4.4 Traceability
Decisions, assessments, approvals and material measures relating to information security must be documented in a traceable manner.
### 4.5 Continual improvement
The ISMS is reviewed regularly and adjusted where necessary. Findings from audits, incidents, risks, changes and management reviews feed into the improvement.
## 5. Information security requirements
<!-- REQ 1.1.1-S1 -->
{{#if FLAG_INCLUDE_SHOULD}}The information security requirements are based on the strategy of {{ORG_NAME}}; legal and contractual requirements are taken into account. {{/if}}The organisation determines and documents information security requirements on the basis of:
- legal and regulatory requirements,
- contractual requirements, in particular from customers and partners,
- requirements from the VDA ISA,
- internal business requirements,
- results of risk analyses,
- protection needs of information, processes and IT systems,
- requirements from projects, changes and external IT services.
The relevant requirements in each case are taken into account in the ISMS and implemented through suitable policies, processes, technical measures and evidence.
## 6. Roles and responsibilities
The organisation defines roles and responsibilities for information security. These include at least:
| Role | Fundamental responsibility |
|-------|------------------------------|
| {{ROLE_MANAGEMENT}} | Overall responsibility, approval of the information security policy, provision of appropriate resources |
| {{ROLE_ISB}} | Steering, maintenance and further development of the ISMS |
| Managers | Implementation of the requirements within their respective area of responsibility |
| {{ROLE_IT_LEAD}} | Implementation of technical and organisational security measures in the IT area |
| Asset owners / process owners | Assessment and maintenance of relevant information, processes and assets in the ISMS tool |
| Employees | Compliance with the policies and reporting of security events |
| External service providers | Compliance with contractually agreed security requirements |
The specific assignment of roles and responsibilities is maintained in the ISMS tool ({{TOOL_NAME}}) or in a supplementary role matrix (see also {{LINK:R01}}).
## 7. Binding nature
<!-- REQ 1.1.1-M2 -->
<!-- REQ 1.1.1-S2 -->
This policy is approved by {{ROLE_MANAGEMENT}} and is binding for all affected persons within the scope. {{#if FLAG_INCLUDE_SHOULD}}Violations of information security requirements may lead to organisational, employment-law or contractual measures. {{/if}}All employees are obliged to:
- comply with the applicable information security policies,
- handle information requiring protection appropriately,
- report security events or suspected cases without delay,
- use only approved systems, applications and services,
- report identified vulnerabilities or risks to the responsible body.
## 8. Publication and communication
<!-- REQ 1.1.1-M4 -->
<!-- REQ 1.1.1-M5 -->
The information security policy is made known to the relevant persons in a suitable form; employees and affected external partners are informed about relevant changes. This can be done via:
- publication in the ISMS tool ({{TOOL_NAME}}),
- internal wiki or document management system,
- onboarding process,
- awareness training (see {{LINK:R05}}),
- direct communication to the affected target groups.
## 9. Review and update
<!-- REQ 1.1.1-S4 -->
This policy is reviewed regularly, but at least:
- {{REVIEW_CYCLE}},
- upon material changes to the ISMS scope,
- upon material organisational or technical changes,
- in the event of relevant security incidents,
- upon new or changed regulatory, legal or contractual requirements.
Changes are documented and approved by {{ROLE_MANAGEMENT}}.
## 10. Evidence
The evidence for the implementation of this policy is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 11. Related documents
<!-- REQ 1.1.1-S3 -->
Further topic-specific security policies (R01–R14) are established and coordinated with one another.
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- ISMS organisation and roles: {{LINK:R01}}
- All thematic policies: {{LINK:R01}} … {{LINK:R14}}
<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool über die Hidden-Anker aufgelöst. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
## Annex A — Information security policy, objectives and communication
*Requirement reference:* ISO/IEC 27001 5.2, 6.2, 7.4, A.5.1
**Requirement**
<!-- REQ 5.2-1 -->
- **[ISO 5.2]** An information security policy is established that fits the organisation, sets objectives, commits to meeting requirements and to continual improvement, and is communicated and available.
<!-- REQ 6.2-1 -->
- **[ISO 6.2]** Information security objectives are established for relevant functions and levels, and their achievement is planned.
<!-- REQ 7.4-1 -->
- **[ISO 7.4]** The internal and external communications relevant to the ISMS are determined.
<!-- REQ A.5.1-1 -->
- **[ISO A.5.1]** The information security policy and topic-specific policies are defined, approved by management, published, communicated, acknowledged and reviewed at planned intervals.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-LEITLINIE -->
This policy is approved by {{ROLE_MANAGEMENT}}, published in {{TOOL_NAME}} and made known to all staff and relevant third parties; acknowledgement is recorded per version. It is reviewed at least {{POLICY_REVIEW_CYCLE}} and upon significant change (BL-GOV-03). The thematic policies and the procedures elaborate it and follow the same approval and review cycle. The information security objectives are stated in measurable terms and held in {{TOOL_NAME}} with target value, responsible role and due date; their achievement is evaluated {{MGMT_REVIEW_CYCLE}}. For internal and external communication on information security it is defined what is communicated, when, with whom and by whom; the central point of contact is {{ROLE_ISB}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/P01_Prototypenschutz.md
+60
View File
@@ -0,0 +1,60 @@
# Policy Prototype Protection
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the protection of prototypes and development objects requiring protection (assessment objective prototype protection, VDA ISA chapter 8). It elaborates the information security policy ({{LINK:L00}}) and is operationalised by the procedure {{LINK:VA-20}}.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}), insofar as prototypes or development objects requiring protection are processed, stored or transported.
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA, chapter 8) and **Implementation at {{ORG_NAME}}**.
{{#if FLAG_PROTOTYPE_PROTECTION}}
### 3.1 Physical security and perimeter (ISA 8.1.1)
**Requirement**
<!-- REQ 8.1.1-M1 -->
- **[MUST]** Areas in which prototypes are processed or stored are protected by defined security zones and an effective perimeter.
**Implementation at {{ORG_NAME}}**
Prototype areas are designated as a dedicated security zone with access control, perimeter protection and logging. Access is limited to authorised persons.
### 3.2 Confidentiality and classification (ISA 8.2.1)
**Requirement**
<!-- REQ 8.2.1-M1 -->
- **[MUST]** Confidentiality obligations exist for prototypes; the associated information is classified and labelled accordingly.
**Implementation at {{ORG_NAME}}**
All persons involved with prototypes (internal and external) sign confidentiality agreements. Prototypes and associated documents are classified as confidential or higher in accordance with the classification scheme.
### 3.3 Transport and storage (ISA 8.3.1)
**Requirement**
<!-- REQ 8.3.1-M1 -->
- **[MUST]** Transport and storage of prototypes are carried out according to documented protection requirements that ensure confidentiality and integrity.
**Implementation at {{ORG_NAME}}**
Transport and storage follow the procedure {{LINK:VA-20}}: secured containers, logged handovers, access and visual protection as well as traceability.
{{/if}}
seed/isms-vorlagenpaket-v2-en/richtlinien/R01_ISMS-Organisation-und-Rollen.md
+294
View File
@@ -0,0 +1,294 @@
# Policy ISMS Organisation and Roles
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the structure, steering and responsibilities of the ISMS of {{ORG_NAME}} as well as the consideration of information security in projects. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Steering of information security
<!-- FW:REF-START ORIG:(ISA 1.2.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 5.1, A.5.4{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.1-M1 -->
- **[MUST]** The scope of the ISMS (the organisation governed by the ISMS) is defined.
<!-- REQ 1.2.1-M2 -->
- **[MUST]** The organisation's requirements for the ISMS are determined.
<!-- REQ 1.2.1-M3 -->
- **[MUST]** The organisation's management has commissioned and approved the ISMS.
<!-- REQ 1.2.1-M4 -->
- **[MUST]** The ISMS provides management with suitable means for monitoring and steering (e.g. management review).
<!-- REQ 1.2.1-M5 -->
- **[MUST]** The applicable controls are determined (e.g. ISO 27001 statement of applicability or a completed ISA catalogue).
<!-- REQ 1.2.1-M6 -->
- **[MUST]** The effectiveness of the ISMS is reviewed regularly by management.
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 5.1-1 -->
- **[ISO 5.1]** Top management demonstrates leadership and commitment with respect to the ISMS.
<!-- REQ A.5.4-1 -->
- **[ISO A.5.4]** Management requires all personnel to apply information security in accordance with the established requirements.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.2.1 -->
The ISMS scope, the requirements and the applicable controls (statement of applicability / ISA catalogue) are documented in the ISMS tool ({{TOOL_NAME}}). {{ROLE_MANAGEMENT}} has commissioned and approved the ISMS by management decision, provides resources and reviews its effectiveness at least {{REVIEW_CYCLE}} in a documented management review; operational steering rests with {{ROLE_ISB}}.
### 3.2 Organisation of information security
<!-- FW:REF-START ORIG:(ISA 1.2.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 5.3, 7.1, A.5.2, A.5.3{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.2-M1 -->
- **[MUST]** Responsibilities for information security are defined, documented and assigned.
<!-- REQ 1.2.2-M2 -->
- **[MUST]** The responsible employees are defined, qualified and enabled for their task.
<!-- REQ 1.2.2-M3 -->
- **[MUST]** The necessary resources are available.
<!-- REQ 1.2.2-M4 -->
- **[MUST]** The points of contact are known within the organisation and to relevant business partners.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.2-S1 -->
- **[SHOULD]** An appropriate information security structure within the organisation is defined and documented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.2-S2 -->
- **[SHOULD]** Security-relevant roles that are not part of the ISMS but are relevant to information security are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.2.2-H1 -->
- **[HIGH]** An appropriate organisational separation of responsibilities is established to avoid conflicts of interest (segregation of duties). (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 5.3-1 -->
- **[ISO 5.3]** Responsibilities and authorities for security-relevant roles are assigned and communicated.
<!-- REQ 7.1-1 -->
- **[ISO 7.1]** The resources needed for the ISMS are determined and provided.
<!-- REQ A.5.2-1 -->
- **[ISO A.5.2]** Information security roles and responsibilities are defined and allocated.
<!-- REQ A.5.3-1 -->
- **[ISO A.5.3]** Conflicting duties and areas of responsibility are segregated to reduce unauthorised or unintentional modification and misuse.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.2.2 -->
Responsibilities are documented in the role/responsibility matrix and in the ISMS tool ({{TOOL_NAME}}) and made known to the role holders as well as to relevant business partners. The role {{ROLE_ISB}} is appointed, qualified, equipped with resources and authority, and reports directly to {{ROLE_MANAGEMENT}}.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.2.2-elev -->
Where the protection need is high, an organisational segregation of duties (e.g. implementation vs. control) is established; unavoidable dual roles are safeguarded by compensating controls (four-eyes principle).
{{/if}}
### 3.3 Information security in projects
<!-- FW:REF-START ORIG:(ISA 1.2.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.8{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.3-M1 -->
- **[MUST]** Projects are classified taking information security requirements into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S1 -->
- **[SHOULD]** Procedures and criteria for classifying projects are documented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S2 -->
- **[SHOULD]** A risk assessment following the defined procedure is carried out in an early project phase and repeated upon project changes.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S3 -->
- **[SHOULD]** Measures are derived for identified information security risks and taken into account in the project.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.2.3-H1 -->
- **[HIGH]** The derived measures are reviewed regularly during the project and reassessed when the assessment criteria change. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.8-1 -->
- **[ISO A.5.8]** Information security is integrated into project management.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.2.3 -->
At the outset, projects are classified with regard to their information security needs on the basis of the documented catalogue of criteria (BL-PROJ-01); classification, risk assessment and derived measures are maintained in the project register ({{LINK:REG-PROJECTS}}). In an early project phase and upon changes, a risk assessment is carried out following the procedure Information Security in Projects ({{LINK:VA-19}}); measures are tracked as tasks in {{TOOL_TICKET}} and reviewed before project completion. The project management is responsible; where the protection need is elevated, {{ROLE_ISB}} is involved.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.2.3-elev -->
Where the protection need is high, the derived measures are reviewed continuously over the course of the project and reassessed when the assessment criteria change.
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_MANAGEMENT}} | Commissioning, overall responsibility, management review |
| {{ROLE_ISB}} | Operational steering of the ISMS |
| {{ROLE_IT_LEAD}} | Technical implementation |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:L00}}, {{LINK:R03}}, {{LINK:R13}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Context, interested parties and scope of the ISMS
*Requirement reference:* ISO/IEC 27001 4.1, 4.2, 4.3, 4.4
**Requirement**
<!-- REQ 4.1-1 -->
- **[ISO 4.1]** Internal and external issues that affect the ability to achieve the ISMS objectives are determined and kept up to date.
<!-- REQ 4.2-1 -->
- **[ISO 4.2]** The interested parties relevant to the ISMS and their information security requirements are determined.
<!-- REQ 4.3-1 -->
- **[ISO 4.3]** The scope of the ISMS is determined considering the issues, requirements and interfaces, and maintained as documented information.
<!-- REQ 4.4-1 -->
- **[ISO 4.4]** An ISMS is established, implemented, maintained and continually improved.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-KONTEXT -->
Internal and external issues as well as the relevant interested parties and their requirements are maintained in {{TOOL_NAME}} as a context and stakeholder analysis and updated at least {{POLICY_REVIEW_CYCLE}} and upon significant change. The scope of the ISMS ({{ISMS_SCOPE}}) is documented information and names sites, processes, organisational units and IT services as well as interfaces and dependencies on third parties; exclusions are justified. The ISMS is operated according to the PDCA cycle and continually improved. Responsible: {{ROLE_ISB}}; approval: {{ROLE_MANAGEMENT}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Planning of changes to the ISMS
*Requirement reference:* ISO/IEC 27001 6.3
**Requirement**
<!-- REQ 6.3-1 -->
- **[ISO 6.3]** Changes to the ISMS are carried out in a planned manner.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-CHANGE -->
Changes to the ISMS — scope, organisation, roles, key processes or systems — are planned, assessed before implementation and documented in {{TOOL_NAME}}. The assessment covers the purpose and potential consequences of the change, effects on risks and controls, the resources required and the assignment of responsibilities. Approval is given by {{ROLE_MANAGEMENT}}; technical changes additionally run through change management (BL-OPS-09, see {{LINK:VA-04}}).
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.6 Control of documented information
*Requirement reference:* ISO/IEC 27001 7.5.1, 7.5.2, 7.5.3
**Requirement**
<!-- REQ 7.5.1-1 -->
- **[ISO 7.5.1]** The ISMS includes the documented information required by the standard and that determined as necessary.
<!-- REQ 7.5.2-1 -->
- **[ISO 7.5.2]** When creating and updating documented information, identification, format and medium as well as review and approval are ensured.
<!-- REQ 7.5.3-1 -->
- **[ISO 7.5.3]** Documented information is controlled: availability, protection, distribution, access, retention and change control.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-DOKU -->
The documented information of the ISMS is maintained in {{TOOL_NAME}}. Every document carries a title, a unique identifier, version, date, status, responsible role and approver; creation and modification pass through review and four-eyes approval (BL-GOV-03). Control ensures availability to the authorised roles, protection against unauthorised modification, managed distribution, version control with a change history and retention of superseded versions ({{RECORDS_RETENTION}}). Documents of external origin are identified and controlled in the same way. Review cycle: {{POLICY_REVIEW_CYCLE}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.7 Contact with authorities and interest groups
*Requirement reference:* ISO/IEC 27001 A.5.5, A.5.6
**Requirement**
<!-- REQ A.5.5-1 -->
- **[ISO A.5.5]** Appropriate contacts with relevant authorities are established and maintained.
<!-- REQ A.5.6-1 -->
- **[ISO A.5.6]** Appropriate contacts with special interest groups, professional forums and security associations are maintained.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-KONTAKTE -->
{{ROLE_ISB}} maintains a contact list of the relevant authorities and reporting bodies ({{AUTHORITY_CONTACTS}}) with responsibility, availability and reporting channel; it is checked for currency {{POLICY_REVIEW_CYCLE}} and is available in an emergency without IT access. Reporting obligations and deadlines are held in the incident procedure ({{LINK:VA-01}}). In addition, professional contacts with interest groups, forums and security associations are maintained; the resulting insights feed into the evaluation of threat intelligence.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R02_Asset-und-Klassifizierungsrichtlinie.md
+259
View File
@@ -0,0 +1,259 @@
# Policy Asset and Classification Policy
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the identification, classification and protected handling of information assets as well as the approval of hardware and software. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Identification of information assets
<!-- FW:REF-START ORIG:(ISA 1.3.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.9{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.1-M1 -->
- **[MUST]** The organisation's information assets and other security-relevant assets are identified and recorded.
<!-- REQ 1.3.1-M2 -->
- **[MUST]** The supporting assets that process the information assets are identified and recorded.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.1-S1 -->
- **[SHOULD]** A catalogue of the relevant information assets exists; the relevant aspects are taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.9-1 -->
- **[ISO A.5.9]** An inventory of information and associated assets, including owners, is established and maintained.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.3.1 -->
Information assets and supporting assets are recorded in the ISMS tool ({{TOOL_NAME}}) in the asset inventory with attributes (owner, location, protection need) and maintained as a catalogue (see {{LINK:VA-08}}); additions and removals are triggered via {{TOOL_TICKET}}.
### 3.2 Classification of information assets
<!-- FW:REF-START ORIG:(ISA 1.3.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.12, A.5.13{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.2-M1 -->
- **[MUST]** A consistent scheme for classifying information assets with regard to the protection goal of confidentiality is in place.
<!-- REQ 1.3.2-M2 -->
- **[MUST]** The identified information assets are assessed according to the defined criteria and assigned to the classification scheme.
<!-- REQ 1.3.2-M3 -->
- **[MUST]** Requirements for handling supporting assets (e.g. labelling, use, transport, storage, return, deletion/destruction) depending on the classification are in place and implemented.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.2-S1 -->
- **[SHOULD]** The protection goals of integrity and availability are taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.12-1 -->
- **[ISO A.5.12]** Information is classified according to its protection needs (confidentiality, integrity, availability).
<!-- REQ A.5.13-1 -->
- **[ISO A.5.13]** Procedures for labelling information in accordance with the classification scheme are developed and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.3.2 -->
A consistent four-tier classification scheme (Public / Internal / Confidential / Strictly confidential) applies for confidentiality; the classification is carried out according to defined criteria by the asset owner in the ISMS tool and also takes integrity and availability into account. Handling requirements per protection class (labelling, storage, transport, transmission BL-CRY-01/04, deletion BL-DEL-01) are defined, implemented and made known (see {{LINK:VA-08}}).
### 3.3 Use of approved external IT services/hardware
<!-- FW:REF-START ORIG:(ISA 1.3.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.10{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.3-M1 -->
- **[MUST]** External IT services are not used without an explicit assessment and implementation of the information security requirements; the relevant aspects are taken into account.
<!-- REQ 1.3.3-M2 -->
- **[MUST]** The external IT services are aligned with the protection need of the information assets processed.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S1 -->
- **[SHOULD]** Requirements for procurement, commissioning and approval in connection with the use of external IT services are determined and met.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S2 -->
- **[SHOULD]** A procedure for approval taking the protection need into account is established.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S3 -->
- **[SHOULD]** External IT services and their approval are documented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S4 -->
- **[SHOULD]** It is regularly verified that only approved external IT services are used.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.10-1 -->
- **[ISO A.5.10]** Rules for the acceptable use and handling of information and assets are defined, documented and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.3.3 -->
External IT services/components are assessed before use, aligned with the protection need and approved via a defined procedure; the approvals are maintained in the register of external IT/cloud/AI services ({{LINK:REG-EXT-SERVICES}}) (supplier {{LINK:VA-10}}, asset {{LINK:VA-08}}) and regularly checked for exclusive use of approved services.
### 3.4 Approval of software
<!-- FW:REF-START ORIG:(ISA 1.3.4) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.19{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.4-M1 -->
- **[MUST]** Software is approved before installation or use; the relevant aspects are taken into account.
<!-- REQ 1.3.4-M2 -->
- **[MUST]** The software approval also applies to special software such as maintenance tools.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S1 -->
- **[SHOULD]** The types of software to be managed (firmware, operating systems, applications, libraries, device drivers) are determined.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S2 -->
- **[SHOULD]** Repositories of the managed software exist.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S3 -->
- **[SHOULD]** The software repositories are protected against unauthorised manipulation.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S4 -->
- **[SHOULD]** The approval of software is reviewed regularly.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S5 -->
- **[SHOULD]** Software versions and patch levels are known.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.3.4-V1 -->
- **[VERY HIGH]** Additional requirements for software use (e.g. the need to control/monitor use) are determined where present. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.19-1 -->
- **[ISO A.8.19]** Procedures and measures for securely managing software installation on operational systems are implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.3.4 -->
Software (incl. special/maintenance software) is approved before use; approved software is maintained in the software whitelist register ({{LINK:REG-SW-WHITELIST}}) with version/patch level, source/supplier ({{LINK:VA-10}}) and approval status and is linked to the asset inventory ({{LINK:VA-08}}); procurement/approval runs via {{TOOL_TICKET}}. Managed software types are determined, repositories protected against manipulation, and approvals are reviewed regularly.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.3.4-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, additional control/monitoring requirements for software use are determined and implemented.{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Asset inventory, approval of hardware/software |
| {{ROLE_ISB}} | Classification scheme |
| Asset owner | Maintenance of individual assets |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-08}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R01}}, {{LINK:R08}}, {{LINK:R11}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Data masking and pseudonymisation
*Requirement reference:* ISO/IEC 27001 A.8.11
**Requirement**
<!-- REQ A.8.11-1 -->
- **[ISO A.8.11]** Data masking is applied in accordance with the access control and privacy requirements.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MASKIERUNG -->
Where the full information content is not required for the purpose, data is masked, pseudonymised or anonymised. This applies in particular to test, training and development environments ({{LINK:R11}}), to analyses and to displays with a restricted need for access. Extent and method follow the classification and the data protection requirements ({{LINK:R14}}); whether the link to a person may be restored, and how that is safeguarded, is governed explicitly.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R03_Risikomanagement-und-Auditrichtlinie.md
+289
View File
@@ -0,0 +1,289 @@
# Policy Risk Management and Audit Policy
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the identification, assessment and treatment of information security risks as well as internal and independent reviews. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Risk management
<!-- FW:REF-START ORIG:(ISA 1.4.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.4.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 6.1.1, 6.1.2, 8.2, 8.3{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.4.1-M1 -->
- **[MUST]** Risk assessments are carried out regularly and on an ad-hoc basis.
<!-- REQ 1.4.1-M2 -->
- **[MUST]** Information security risks are assessed appropriately (e.g. likelihood of occurrence and potential extent of damage).
<!-- REQ 1.4.1-M3 -->
- **[MUST]** Information security risks are documented.
<!-- REQ 1.4.1-M4 -->
- **[MUST]** A responsible person (risk owner) is assigned to each information security risk and is responsible for its assessment and treatment.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S1 -->
- **[SHOULD]** A procedure for the identification, assessment and treatment of security risks is in place.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S2 -->
- **[SHOULD]** Criteria for the assessment and treatment of security risks exist.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S3 -->
- **[SHOULD]** Risk treatment measures and their responsible persons are defined and documented; a measures plan or implementation overview is tracked.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S4 -->
- **[SHOULD]** Upon changes in the environment (e.g. organisational structure, location, regulations), a reassessment is carried out promptly.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 6.1.1-1 -->
- **[ISO 6.1.1]** When planning the ISMS, risks and opportunities that need to be addressed are determined.
<!-- REQ 6.1.2-1 -->
- **[ISO 6.1.2]** A risk assessment process with defined criteria is established and applied so that it is repeatable and produces comparable results.
<!-- REQ 8.2-1 -->
- **[ISO 8.2]** Risk assessments are performed at planned intervals and upon significant change, and are documented.
<!-- REQ 8.3-1 -->
- **[ISO 8.3]** The risk treatment plan is implemented and the results are documented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.4.1 -->
The documented risk management procedure (see {{LINK:VA-09}}) with assessment and acceptance criteria is implemented in the ISMS tool ({{TOOL_NAME}}): risks are identified regularly ({{REVIEW_CYCLE}}) and on an ad-hoc basis, assessed (likelihood × impact) and documented; for each risk, a risk owner, treatment option and measures with deadlines are recorded and tracked. Residual risks are accepted by {{ROLE_MANAGEMENT}} in a documented manner.
### 3.2 Verification of compliance in IS operations
<!-- FW:REF-START ORIG:(ISA 1.5.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.5.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.36{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.5.1-M1 -->
- **[MUST]** Compliance with the policies is reviewed organisation-wide.
<!-- REQ 1.5.1-M2 -->
- **[MUST]** Information security policies and procedures are reviewed regularly.
<!-- REQ 1.5.1-M3 -->
- **[MUST]** Measures to correct possible deviations are initiated and tracked.
<!-- REQ 1.5.1-M4 -->
- **[MUST]** Compliance with information security requirements (e.g. technical specifications) is reviewed regularly.
<!-- REQ 1.5.1-M5 -->
- **[MUST]** The results of the reviews carried out are recorded and retained.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.5.1-S1 -->
- **[SHOULD]** A plan for the content and framework conditions (schedule, scope, controls) of the reviews to be carried out is in place.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.36-1 -->
- **[ISO A.5.36]** Compliance with the information security policy, topic-specific policies, rules and standards is reviewed regularly.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.5.1 -->
Compliance with policies, procedures and technical requirements is reviewed organisation-wide and regularly according to the audit programme ({{LINK:REG-AUDIT-PLAN}}) and the audit/compliance review procedure ({{LINK:VA-15}}) through internal audits and controls (cycle BL-GOV-01); results are recorded and retained, deviations are tracked as measures in {{TOOL_NAME}}; responsible: {{ROLE_ISB}}.
### 3.3 Independent review of the ISMS
<!-- FW:REF-START ORIG:(ISA 1.5.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.5.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 9.2, A.5.35{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.5.2-M1 -->
- **[MUST]** Information security reviews are carried out by an independent and competent body regularly and after fundamental changes.
<!-- REQ 1.5.2-M2 -->
- **[MUST]** Measures to correct possible deviations are initiated and tracked.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.5.2-S1 -->
- **[SHOULD]** The results of the reviews carried out are documented and reported to the organisation's management.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 9.2-1 -->
- **[ISO 9.2]** Internal audits are conducted at planned intervals to verify conformity and effective implementation of the ISMS.
<!-- REQ A.5.35-1 -->
- **[ISO A.5.35]** The organisation's approach to managing information security is reviewed independently at planned intervals.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.5.2 -->
The ISMS is reviewed regularly and after fundamental changes by an independent, competent body (internal audit or external auditing, e.g. TISAX); results are documented, reported to {{ROLE_MANAGEMENT}} and deviations tracked as measures.
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Risk management, audits |
| {{ROLE_MANAGEMENT}} | Risk acceptance |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-09}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R01}}, {{LINK:R04}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Statement of Applicability (SoA)
*Requirement reference:* ISO/IEC 27001 6.1.3
**Requirement**
<!-- REQ 6.1.3-1 -->
- **[ISO 6.1.3]** A risk treatment process is defined; necessary controls are determined and compared against Annex A in a Statement of Applicability.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-SOA -->
The risk treatment determines which controls are necessary; the result is compared against Annex A to identify controls that may have been overlooked. The Statement of Applicability is maintained in {{TOOL_NAME}} and states for each control: applicability, justification for inclusion, origin (risk ID, legal or contractual requirement), implementation status, responsible role, reference to policy and procedure as well as evidence; where a control is excluded, the justification is documented. The risk treatment plan and the acceptance of residual risks are approved by the respective risk owners; the SoA is approved by {{ROLE_MANAGEMENT}} and updated with every risk assessment ({{RISK_REVIEW_CYCLE}}).
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Operational planning and control
*Requirement reference:* ISO/IEC 27001 8.1
**Requirement**
<!-- REQ 8.1-1 -->
- **[ISO 8.1]** The processes needed to meet the requirements are planned, implemented and controlled; planned changes are controlled.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-BETRIEB -->
The processes required to meet the information security requirements are laid down in the procedures and controlled in {{TOOL_NAME}}; for each process the trigger, responsible role, deadlines and evidence are defined. Planned changes are controlled and their consequences assessed; unintended changes are reviewed and corrected where necessary. Outsourced processes are determined and monitored through supplier management ({{LINK:R13}}). Evidence of execution as planned is kept in the evidence register ({{LINK:NACHWEISREGISTER}}).
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.6 Monitoring, measurement, analysis and evaluation
*Requirement reference:* ISO/IEC 27001 9.1
**Requirement**
<!-- REQ 9.1-1 -->
- **[ISO 9.1]** The information security performance and the effectiveness of the ISMS are monitored, measured, analysed and evaluated.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-MESSUNG -->
For the evaluation of information security performance and the effectiveness of the ISMS it is defined what is measured (metrics sheet in {{TOOL_NAME}}), by which method and data source, at which interval, who measures, when the results are analysed and who analyses them. The metrics cover at least incident handling, vulnerability and patch remediation, recertification of access rights, restore tests, awareness participation and open actions; each metric has a target value and a responsible role. Results and trends feed into the management review {{MGMT_REVIEW_CYCLE}}; a deviation from the target value triggers an action.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.7 Management review
*Requirement reference:* ISO/IEC 27001 9.3
**Requirement**
<!-- REQ 9.3-1 -->
- **[ISO 9.3]** Top management reviews the ISMS at planned intervals.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-MGMTREVIEW -->
{{ROLE_MANAGEMENT}} reviews the ISMS at least {{MGMT_REVIEW_CYCLE}} against a fixed agenda (BL-GOV-02). Inputs are at least: status of actions from previous reviews; changes in relevant internal and external issues and in the requirements of interested parties; feedback on information security performance (nonconformities and corrective actions, monitoring and measurement results, audit results, achievement of the information security objectives); feedback from interested parties; results of the risk assessment and status of the risk treatment plan; opportunities for improvement. Outputs are decisions on opportunities for improvement and on any need to change the ISMS, each with a responsible role and a due date. The minutes are retained in {{TOOL_NAME}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.8 Nonconformity, corrective action and continual improvement
*Requirement reference:* ISO/IEC 27001 10.1, 10.2
**Requirement**
<!-- REQ 10.1-1 -->
- **[ISO 10.1]** The suitability, adequacy and effectiveness of the ISMS are continually improved.
<!-- REQ 10.2-1 -->
- **[ISO 10.2]** In the event of nonconformity, corrections are made and corrective actions are taken to eliminate the causes.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-MS-CAPA -->
Nonconformities arising from audits, controls, incidents, deviations of metrics and reports are recorded in {{TOOL_NAME}}. For each case the immediate correction and the handling of the consequences are decided, the cause is analysed and it is evaluated whether similar nonconformities exist or could occur elsewhere. Necessary corrective actions are implemented with a responsible role and a due date; their effectiveness is evaluated after the defined effectiveness interval and, where necessary, risks, controls and documents are adjusted. The nature of the nonconformity, the actions taken and the result of the effectiveness review are retained. The suitability, adequacy and effectiveness of the ISMS are continually improved; evidence is provided through metrics and the management review.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R04_Incident-Notfall-und-Kontinuitaetsrichtlinie.md
+383
View File
@@ -0,0 +1,383 @@
# Policy Incident, Emergency and Continuity Policy
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the reporting and handling of security events, crisis management as well as emergency and continuity planning. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Reporting of security events
<!-- FW:REF-START ORIG:(ISA 1.6.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.24, A.6.8{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.1-M1 -->
- **[MUST]** A definition of a reportable security event or observation exists and is known to employees and relevant stakeholders.
<!-- REQ 1.6.1-M2 -->
- **[MUST]** Appropriate, risk-oriented mechanisms for reporting security events are defined, implemented and known to all relevant reporters.
<!-- REQ 1.6.1-M3 -->
- **[MUST]** Appropriate channels for communicating with reporters exist.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S1 -->
- **[SHOULD]** A common point of contact for event reporting exists.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S2 -->
- **[SHOULD]** Different reporting channels depending on the perceived severity (real-time for serious events/emergencies as well as asynchronous mechanisms such as tickets or email) are available.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S3 -->
- **[SHOULD]** Employees are obliged and trained to report relevant events.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S4 -->
- **[SHOULD]** Security events can also be reported by external parties; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S5 -->
- **[SHOULD]** The mechanism and the information on how incidents are reported are accessible to all relevant reporters.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S6 -->
- **[SHOULD]** A feedback procedure to the reporters is established.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.1-V1 -->
- **[VERY HIGH]** Tests and exercises of event and observation reporting are carried out regularly. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.24-1 -->
- **[ISO A.5.24]** The management of information security incidents is planned and prepared (roles, processes, responsibilities).
<!-- REQ A.6.8-1 -->
- **[ISO A.6.8]** A mechanism for the timely reporting of observed or suspected information security events is provided.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.6.1 -->
A known definition of reportable events and a low-threshold reporting path (report button/form in {{TOOL_TICKET}} or the ISMS tool, email to {{ROLE_ISB}}, real-time channel for serious cases) are available to all employees and external parties; the reporting path is known via onboarding/awareness (BL-HR-01), and a feedback procedure is established (see {{LINK:VA-01}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.1-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, tests and exercises of event reporting are carried out regularly.{{/if}}
{{/if}}
### 3.2 Handling of security events
<!-- FW:REF-START ORIG:(ISA 1.6.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.25, A.5.26, A.5.27, A.5.28{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.2-M1 -->
- **[MUST]** Reported events are processed without undue delay.
<!-- REQ 1.6.2-M2 -->
- **[MUST]** An appropriate response to reported security events is ensured.
<!-- REQ 1.6.2-M3 -->
- **[MUST]** Lessons learned feed into continual improvement.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S1 -->
- **[SHOULD]** During processing, reported events are categorised (e.g. personnel, physical, cyber), qualified (e.g. not security-relevant, observation, improvement suggestion, vulnerability, incident) and prioritised (e.g. low, medium, high, critical).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S2 -->
- **[SHOULD]** Responsibilities for handling events per category are defined and assigned.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S3 -->
- **[SHOULD]** A strategy for reporting potentially criminally relevant aspects to the competent authorities, where necessary, exists. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H1 -->
- **[HIGH]** Maximum response times per class, category and severity are defined. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H2 -->
- **[HIGH]** Events not processed in line with their priority are escalated; the relevant aspects are taken into account. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H3 -->
- **[HIGH]** Legal, regulatory and contractual reporting obligations and the associated contact information are known. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H4 -->
- **[HIGH]** A communication strategy for security-relevant events exists; the relevant aspects are taken into account. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H5 -->
- **[HIGH]** Procedures for responding to security incidents at suppliers are established; the relevant aspects are taken into account. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.2-V1 -->
- **[VERY HIGH]** The handling of events of different categories and priorities is tested regularly; the relevant aspects are taken into account. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.25-1 -->
- **[ISO A.5.25]** Information security events are assessed and a decision is taken whether they are to be categorised as incidents.
<!-- REQ A.5.26-1 -->
- **[ISO A.5.26]** Information security incidents are responded to in accordance with documented procedures.
<!-- REQ A.5.27-1 -->
- **[ISO A.5.27]** Knowledge gained from information security incidents is used to strengthen the controls.
<!-- REQ A.5.28-1 -->
- **[ISO A.5.28]** Procedures for the identification, collection, acquisition and preservation of evidence relating to incidents are established and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.6.2 -->
Events are categorised, qualified, prioritised, handled and documented without delay following a defined incident procedure (see {{LINK:VA-01}}) in {{TOOL_TICKET}}; responsibilities and escalation paths are assigned ({{ROLE_ISB}} coordinates, {{ROLE_IT_LEAD}} implements). Lessons learned feed into improvement; a strategy for reporting to authorities/law enforcement exists.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.2-elev -->
Where the protection need is high, maximum response times per severity are defined, escalations for events not processed in line with their priority are regulated, reporting obligations and contacts are known, and a communication strategy as well as a procedure for supplier incidents are established. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, event handling is tested regularly.{{/if}}
{{/if}}
### 3.3 Crisis management
<!-- FW:REF-START ORIG:(ISA 1.6.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.29{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.3-M1 -->
- **[MUST]** An appropriate plan for responding to and managing crisis situations exists and the necessary resources are available.
<!-- REQ 1.6.3-M2 -->
- **[MUST]** Responsibilities and authorities for crisis management are defined, documented and assigned.
<!-- REQ 1.6.3-M3 -->
- **[MUST]** The responsible employees are defined and qualified for their task.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S1 -->
- **[SHOULD]** Methods for detecting crisis situations are established; general indicators and specific foreseeable crises are identified.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S2 -->
- **[SHOULD]** A procedure for triggering and/or escalating crisis management is in place.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S3 -->
- **[SHOULD]** Strategic objectives and their priority in crisis situations are defined and known to relevant personnel.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S4 -->
- **[SHOULD]** A crisis team is defined and approved.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S5 -->
- **[SHOULD]** Crisis policies and procedures are defined and approved.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S6 -->
- **[SHOULD]** The crisis planning is reviewed and updated regularly.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H1 -->
- **[HIGH]** Relevant different potential crisis scenarios are identified.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H2 -->
- **[HIGH]** The resources and information necessary for crisis management (e.g. communication infrastructure, availability of contact and risk information) are identified; appropriate measures to ensure availability or fallback planning are in place. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H3 -->
- **[HIGH]** A communication strategy for crisis situations exists. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H4 -->
- **[HIGH]** The efficiency, feasibility and appropriateness of the crisis planning are assessed regularly. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H5 -->
- **[HIGH]** Sample-based tests of the crisis planning are carried out (e.g. simulation, tabletop exercises with key personnel). (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.3-V1 -->
- **[VERY HIGH]** Crisis exercises and simulations involving all relevant persons, including decision-makers, are carried out regularly. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.29-1 -->
- **[ISO A.5.29]** The maintenance of information security during disruption is planned and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 1.6.3 -->
A crisis management with a plan, a defined and approved crisis team, roles, triggering/escalation, communication and decision paths as well as strategic objectives is established (triggering/recovery see {{LINK:VA-02}}); the necessary resources are available and the responsible persons are qualified. Detection methods are in place, the crisis planning is reviewed and updated regularly; the crisis team is convened by {{ROLE_MANAGEMENT}}.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.3-elev -->
Where the protection need is high, relevant crisis scenarios are identified, the necessary resources/information and a communication strategy are ensured, and the planning is assessed regularly and tested on a sample basis (tabletop). {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, crisis exercises involving all relevant persons including decision-makers are carried out regularly.{{/if}}
{{/if}}
### 3.4 Continuity planning for IT services
<!-- FW:REF-START ORIG:(ISA 5.2.8) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.8{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.30, A.8.14{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.8-M1 -->
- **[MUST]** Critical IT services are identified and the business impact is taken into account.
<!-- REQ 5.2.8-M2 -->
- **[MUST]** Requirements and responsibilities for the continuity and recovery of these IT services are known to relevant stakeholders and fulfilled.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S1 -->
- **[SHOULD]** Critical IT systems are identified; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S2 -->
- **[SHOULD]** A continuity plan exists and is reviewed and updated regularly.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S3 -->
- **[SHOULD]** The continuity planning covers at least (D)DoS attacks, successful ransomware attacks and other sabotage, system failure scenarios as well as natural disasters affecting critical IT systems.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H1 -->
- **[HIGH]** The continuity planning contains predefined time frames (recovery time objective) for the resumption of operations. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H2 -->
- **[HIGH]** Appropriate SLAs with external service providers in line with the continuity planning are in place. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H3 -->
- **[HIGH]** The continuity plans include the coordination of contractually agreed communication with business partners. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H4 -->
- **[HIGH]** The continuity planning is tested regularly, incl. full recovery to a known state and adherence to defined target times. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H5 -->
- **[HIGH]** A backup and recovery strategy for critical IT services and information is defined and implemented. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H6 -->
- **[HIGH]** Backups of critical IT services and information are sufficiently protected against unauthorised modification/deletion by malware. (I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H7 -->
- **[HIGH]** Backups of critical IT services and information are sufficiently protected against unauthorised access by malware or operators. (C, I)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V1 -->
- **[VERY HIGH]** The continuity planning is coordinated with the continuity plans of relevant external service providers. (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V2 -->
- **[VERY HIGH]** The continuation of essential core and business functions with minimal or no loss of operational continuity is possible; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V3 -->
- **[VERY HIGH]** The continuity planning is tested regularly. Test scenarios, results and lessons learned are recorded. (I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.30-1 -->
- **[ISO A.5.30]** ICT readiness is planned, implemented and tested on the basis of the business continuity objectives and requirements.
<!-- REQ A.8.14-1 -->
- **[ISO A.8.14]** Information processing facilities are implemented with sufficient redundancy to meet the availability requirements.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.8 -->
Critical IT services are recorded with their business impact in the register of critical IT services ({{LINK:REG-CRIT-SERVICES}}) (incl. BIA classification, RTO/RPO, recovery sequence); requirements and responsibilities for continuity/recovery are known and fulfilled. A continuity plan (incl. (D)DoS, ransomware, failure, natural disasters) exists, is reviewed regularly and implemented via the IT emergency procedure (see {{LINK:VA-02}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.8-elev -->
Where the protection need is high, RTO/RPO, SLAs with service providers, partner communication, regular full tests as well as a protected backup/recovery strategy (immutable/isolated) are established. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, the planning is coordinated with external service providers, the continuation of essential functions is ensured, and tests incl. lessons learned are recorded.{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Incident coordination |
| {{ROLE_IT_LEAD}} | Emergency/recovery planning |
| {{ROLE_MANAGEMENT}} | Crisis team |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-01}}, {{LINK:VA-02}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R03}}, {{LINK:R10}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R05_Personalsicherheit-und-Awareness.md
+221
View File
@@ -0,0 +1,221 @@
# Policy Personnel Security and Awareness
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_HR_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs the suitability, contractual commitment as well as training and awareness of personnel. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Qualification for sensitive activities
<!-- FW:REF-START ORIG:(ISA 2.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 7.2, A.6.1{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.1-M1 -->
- **[MUST]** Sensitive work areas and activities are determined.
<!-- REQ 2.1.1-M2 -->
- **[MUST]** The requirements for employees with regard to their job profiles are determined and met.
<!-- REQ 2.1.1-M3 -->
- **[MUST]** The identity of potential employees is verified (e.g. checking of identity documents).
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.1-S1 -->
- **[SHOULD]** The personal suitability of potential employees is checked using simple methods (e.g. job interview).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.1-S2 -->
- **[SHOULD]** An extended suitability check depending on the work area and the activity is carried out (e.g. assessment centre, checking of references, certificates and criminal record certificates).
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 7.2-1 -->
- **[ISO 7.2]** The necessary competence is determined and ensured; corresponding evidence is retained.
<!-- REQ A.6.1-1 -->
- **[ISO A.6.1]** Background verification of candidates is carried out appropriately to the business requirements and in accordance with the law.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 2.1.1 -->
Sensitive work areas and activities are determined in the register of sensitive activities ({{LINK:REG-SENS-ROLES}}) and recorded with the required depth of checking; requirements for positions are documented in job descriptions and are met. Identity verification as well as the personal and — for sensitive roles — extended suitability check (interview, references, criminal record certificate within the legally permissible scope) are carried out following the suitability and verification procedure ({{LINK:VA-14}}); responsible: {{ROLE_HR_LEAD}}; evidence in the personnel file.
### 3.2 Contractual commitment of personnel
<!-- FW:REF-START ORIG:(ISA 2.1.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.6.2, A.6.5, A.6.6{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.2-M1 -->
- **[MUST]** A confidentiality obligation is in force.
<!-- REQ 2.1.2-M2 -->
- **[MUST]** An obligation to comply with the information security policies is in force.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S1 -->
- **[SHOULD]** A confidentiality obligation going beyond the employment contract is in force.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S2 -->
- **[SHOULD]** Information security aspects are taken into account in the employees' employment contracts.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S3 -->
- **[SHOULD]** A procedure for dealing with violations of these obligations is described.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.6.2-1 -->
- **[ISO A.6.2]** The employment agreements state the responsibilities for information security.
<!-- REQ A.6.5-1 -->
- **[ISO A.6.5]** Continuing information security responsibilities after termination or change of employment are defined and enforced.
<!-- REQ A.6.6-1 -->
- **[ISO A.6.6]** Confidentiality or non-disclosure agreements are identified, documented and reviewed regularly.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 2.1.2 -->
All employees are contractually obliged upon joining to confidentiality and to compliance with the information security policies ({{ROLE_HR_LEAD}}); information security aspects are part of the employment contracts, and confidentiality continues to apply after termination. A documented procedure for dealing with violations (see {{LINK:VA-14}}) is established; the evidence is kept in the personnel file.
### 3.3 Awareness and training
<!-- FW:REF-START ORIG:(ISA 2.1.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 7.3, A.6.3{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.3-M1 -->
- **[MUST]** Employees are trained and made aware.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S1 -->
- **[SHOULD]** A concept for the awareness and training of employees is created.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S2 -->
- **[SHOULD]** Target groups for training and awareness measures (e.g. managers, administrators, employees with access to customer networks, production personnel) are identified and taken into account in the concept.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S3 -->
- **[SHOULD]** The concept is approved by the responsible management.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S4 -->
- **[SHOULD]** Training and awareness measures are carried out regularly and on an ad-hoc basis.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S5 -->
- **[SHOULD]** Participation in training and awareness measures is documented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S6 -->
- **[SHOULD]** Points of contact for information security are known to the employees.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ 7.3-1 -->
- **[ISO 7.3]** Persons under the organisation's control are aware of the policy, their contribution and the consequences of non-conformance.
<!-- REQ A.6.3-1 -->
- **[ISO A.6.3]** Personnel receive appropriate awareness, education and training as well as regular updates of the relevant policies.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 2.1.3 -->
A role-specific training/awareness concept approved by management (BL-HR-01) is established; employees are trained upon joining and thereafter at least {{REVIEW_CYCLE}} and on an ad-hoc basis (process see {{LINK:VA-12}}). Target groups are identified, records of participation are kept in {{TOOL_NAME}}, points of contact for information security are known; the effectiveness is checked (e.g. phishing simulation).
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_HR_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_HR_LEAD}} | Commitment, suitability |
| {{ROLE_ISB}} | Awareness/training |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_HR_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-12}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R01}}, {{LINK:R06}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Handling of violations
*Requirement reference:* ISO/IEC 27001 A.6.4
**Requirement**
<!-- REQ A.6.4-1 -->
- **[ISO A.6.4]** A disciplinary process for information security violations is established and communicated.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-DISZIPLIN -->
A graduated, documented process applies to violations of the information security requirements and is communicated in advance. It takes into account the nature and severity of the violation, intent or negligence, repetition and the training status of the person concerned. The process is run by {{ROLE_HR_LEAD}} in coordination with {{ROLE_ISB}}; employment law requirements and co-determination rights are observed. Its application is documented confidentially.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R06_Mobiles-Arbeiten-und-mobile-Geraete.md
+151
View File
@@ -0,0 +1,151 @@
# Policy Mobile Working and Mobile Devices
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs mobile working as well as the handling of mobile IT devices and data media. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
{{#if FLAG_MOBILE_WORK}}
### 3.1 Mobile working
<!-- FW:REF-START ORIG:(ISA 2.1.4) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.6.7{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.4-M1 -->
- **[MUST]** The requirements for mobile working are determined and met; the relevant aspects are taken into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.4-S1 -->
- **[SHOULD]** The relevant aspects of mobile working are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.4-S2 -->
- **[SHOULD]** Awareness of employees.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 2.1.4-H1 -->
- **[HIGH]** Protective measures against eavesdropping and being overlooked are implemented. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.6.7-1 -->
- **[ISO A.6.7]** Security measures for working outside the organisation's premises are implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 2.1.4 -->
Mobile working is defined in this policy and the associated mobile working rule (stored in {{TOOL_NAME}}) and the requirements are met; access is exclusively via {{TECH_VPN}} with MFA (BL-IAM-02) and approved, encrypted devices (BL-CRY-03). Employees are made aware (BL-HR-01).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 2.1.4-elev -->
Where the protection need is high, protective measures against eavesdropping and being overlooked are implemented (e.g. privacy screen, quiet environment, clean screen).
{{/if}}
{{/if}}
{{#if FLAG_MOBILE_DEVICES}}
### 3.2 Mobile IT devices and data media
<!-- FW:REF-START ORIG:(ISA 3.1.4) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 3.1.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.7.9, A.7.10, A.8.1{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 3.1.4-M1 -->
- **[MUST]** The requirements for mobile IT devices and mobile data media are determined and met; the relevant aspects are taken into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.4-S1 -->
- **[SHOULD]** Registration of the IT devices.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 3.1.4-H1 -->
- **[HIGH]** General encryption of mobile data media or of the information assets stored on them. Where technically not feasible, information is protected by equivalent measures. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.7.9-1 -->
- **[ISO A.7.9]** Assets used outside the premises are protected.
<!-- REQ A.7.10-1 -->
- **[ISO A.7.10]** Storage media are protected throughout their life cycle (acquisition, use, transport, disposal) in accordance with the classification scheme.
<!-- REQ A.8.1-1 -->
- **[ISO A.8.1]** Information stored on, processed by or accessible via user endpoint devices is protected.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 3.1.4 -->
The requirements for mobile devices and data media are determined and met: devices are registered and centrally managed via {{TECH_MDM}}, only approved devices are used; loss is reported via the reporting path (R04) and {{TOOL_TICKET}}, blocking/wiping upon loss via {{TECH_MDM}} (BL-EP-02).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 3.1.4-elev -->
Where the protection need is high, mobile data media or the information stored on them are generally encrypted (BL-CRY-03); where not feasible, equivalent protective measures apply.
{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Security requirements |
| {{ROLE_IT_LEAD}} | Technical implementation |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R05}}, {{LINK:R07}}, {{LINK:R08}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R07_Physische-Sicherheit.md
+173
View File
@@ -0,0 +1,173 @@
# Policy Physical Security
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs physical protection through security zones, access protection and the handling of supporting utilities. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Security zones and access
<!-- FW:REF-START ORIG:(ISA 3.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 3.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.7.1, A.7.2, A.7.3, A.7.4, A.7.6{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 3.1.1-M1 -->
- **[MUST]** A security zone concept including associated protective measures based on the requirements for handling information assets is in place.
<!-- REQ 3.1.1-M2 -->
- **[MUST]** The defined protective measures are implemented.
<!-- REQ 3.1.1-M3 -->
- **[MUST]** The code of conduct for security zones is known to all persons involved.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S1 -->
- **[SHOULD]** Procedures for granting and revoking access rights are established.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S2 -->
- **[SHOULD]** Policies for visitor management (including registration and escorting of visitors) are defined.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S3 -->
- **[SHOULD]** Policies for carrying and using mobile IT devices and data media (e.g. registration, labelling obligations) are defined and implemented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S4 -->
- **[SHOULD]** Network/infrastructure components (own or customer networks) are protected against unauthorised access.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S5 -->
- **[SHOULD]** External premises used for storing/processing information assets are taken into account in the zone concept (e.g. storage rooms, workshops, test tracks, data centres).
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 3.1.1-H1 -->
- **[HIGH]** Protective measures against simple eavesdropping and being overlooked are implemented. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.7.1-1 -->
- **[ISO A.7.1]** Security perimeters are defined and used to protect areas containing information and assets.
<!-- REQ A.7.2-1 -->
- **[ISO A.7.2]** Secure entry controls and entry points are established to restrict access to authorised persons.
<!-- REQ A.7.3-1 -->
- **[ISO A.7.3]** Physical security for offices, rooms and facilities is designed and implemented.
<!-- REQ A.7.4-1 -->
- **[ISO A.7.4]** Premises are continuously monitored for unauthorised physical access.
<!-- REQ A.7.6-1 -->
- **[ISO A.7.6]** Measures for working in secure areas are defined and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 3.1.1 -->
A security zone concept (BL-PHY-01) with implemented protective measures and a known code of conduct is in place; access rights are granted on a needs-oriented basis via {{TOOL_TICKET}}, documented and revoked when no longer needed (BL-PHY-02, process see {{LINK:VA-17}}). Visitor management, rules for mobile devices, protection of network/infrastructure components and external premises are taken into account.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 3.1.1-elev -->
Where the protection need is high, additional protective measures against simple eavesdropping and being overlooked are implemented.
{{/if}}
<!-- Scope-Hinweis (E2): ISA 3.1.2 ist in VDA-ISA 2027 deprecated; ISA 3.1.3 existiert nicht.
Daher kein Abschnitt/REQ/IMPL für 3.1.2/3.1.3 in R07 und mapping.json. -->
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Zones, access, utilities |
| {{ROLE_ISB}} | Specifications |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R02}}, {{LINK:R06}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.2 Environmental protection, utilities, cabling and maintenance
*Requirement reference:* ISO/IEC 27001 A.7.5, A.7.8, A.7.11, A.7.12, A.7.13
**Requirement**
<!-- REQ A.7.5-1 -->
- **[ISO A.7.5]** Protection against physical and environmental threats is designed and implemented.
<!-- REQ A.7.8-1 -->
- **[ISO A.7.8]** Equipment is sited securely and protected.
<!-- REQ A.7.11-1 -->
- **[ISO A.7.11]** Facilities are protected against failure and disruption of supporting utilities such as power and air conditioning.
<!-- REQ A.7.12-1 -->
- **[ISO A.7.12]** Power and data cabling is protected against interception, interference and damage.
<!-- REQ A.7.13-1 -->
- **[ISO A.7.13]** Equipment is maintained properly to ensure availability and integrity.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-PHY-UMWELT -->
Sites and technical facilities are protected against physical and environmental threats (BL-PHY-03): early fire detection, protection against water and moisture, temperature and humidity monitoring in technical rooms as well as consideration of site-specific hazards. Equipment is sited so that observation, unauthorised access and environmental risks are minimised. Power and air conditioning for critical systems are designed to be uninterruptible and are tested regularly. Power and data cabling is protected against damage and unauthorised access and is documented. Equipment is maintained according to the manufacturer's specifications; maintenance is carried out only by authorised personnel, is planned and recorded, and is supervised where performed externally.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.3 Clear desk and screen lock
*Requirement reference:* ISO/IEC 27001 A.7.7
**Requirement**
<!-- REQ A.7.7-1 -->
- **[ISO A.7.7]** Rules for a clear desk and locked screens are defined and implemented.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-PHY-CLEARDESK -->
Binding rules apply for a clear desk and locked screens (BL-PHY-04): protected documents and media are locked away when unattended; screens are locked when leaving the workplace and lock automatically after {{SESSION_TIMEOUT}}. Printouts are collected immediately and documents no longer required are destroyed according to their protection needs (BL-DEL-01). The rules also apply when working from home and at mobile workplaces ({{LINK:R06}}); compliance is checked on a sample basis.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md
+314
View File
@@ -0,0 +1,314 @@
# Policy Identity and Access Management
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs means of identification, secure log-on, account management as well as the granting and control of access rights. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Handling of means of identification
<!-- FW:REF-START ORIG:(ISA 4.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.16{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.1-M1 -->
- **[MUST]** The requirements for handling means of identification throughout the entire lifecycle are determined and met; the relevant aspects are taken into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.1-S1 -->
- **[SHOULD]** Means of identification can only be created under controlled conditions.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.1.1-H1 -->
- **[HIGH]** A strategy for blocking or invalidating means of identification in the event of loss is prepared and, as far as possible, implemented. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.16-1 -->
- **[ISO A.5.16]** The full life cycle of identities is managed.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 4.1.1 -->
Means of identification (user IDs, tokens, certificates) are assigned throughout the lifecycle uniquely to a person and under controlled conditions via the central directory ({{TOOL_IAM}}); issuance, withdrawal and blocking are requested, approved and documented in {{TOOL_TICKET}} (BL-IAM-07, see {{LINK:VA-03}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.1.1-elev -->
Where the protection need is high, an implemented strategy for blocking/invalidating means of identification in the event of loss is in place.
{{/if}}
### 3.2 Secure log-on
<!-- FW:REF-START ORIG:(ISA 4.1.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.2-M1 -->
- **[MUST]** The user authentication procedures are selected on the basis of a risk assessment; possible attack scenarios (e.g. direct reachability via the internet) have been taken into account.
<!-- REQ 4.1.2-M2 -->
- **[MUST]** State-of-the-art user authentication procedures are applied.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S1 -->
- **[SHOULD]** The authentication procedures are defined and implemented on the basis of business and security requirements.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S2 -->
- **[SHOULD]** Users are authenticated at least by strong passwords in line with established and recognised practices.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S3 -->
- **[SHOULD]** For privileged user accounts, higher-grade procedures are used (e.g. privileged access management, two-factor authentication).
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.1.2-H1 -->
- **[HIGH]** Depending on the risk assessment, authentication and access control are strengthened by supplementary measures (e.g. continuous access monitoring, strong authentication, automatic log-off, lock upon inactivity, brute-force prevention). (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.1.2-V1 -->
- **[VERY HIGH]** Before accessing data with a very high protection need, users are authenticated by means of strong authentication (e.g. two-factor) in line with the state of the art. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.5-1 -->
- **[ISO A.8.5]** Secure authentication technologies and procedures are used on the basis of the access restrictions and the access control policy.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 4.1.2 -->
The authentication procedures are selected on a risk basis and correspond to the state of the art; password requirements per BL-IAM-01 (at least {{PW_MIN_LENGTH}} characters, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) are enforced via the central directory ({{TOOL_IAM}}). For remote access, administrative access and cloud services, MFA (BL-IAM-02) is enforced via {{TECH_MFA}}; privileged accounts use higher-grade procedures (PAM).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.1.2-elev -->
Where the protection need is high, authentication/access control are strengthened by supplementary measures (access monitoring, auto-logout BL-IAM-03, lock BL-IAM-04, brute-force protection). {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, access is only granted after strong authentication (two-factor).{{/if}}
{{/if}}
### 3.3 User accounts and log-on information
<!-- FW:REF-START ORIG:(ISA 4.1.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.17{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.3-M1 -->
- **[MUST]** The creation, modification and deletion of user accounts is carried out.
<!-- REQ 4.1.3-M2 -->
- **[MUST]** Unique and personalised user accounts are used.
<!-- REQ 4.1.3-M3 -->
- **[MUST]** The use of shared accounts is regulated (e.g. limited to cases where traceability is dispensable).
<!-- REQ 4.1.3-M4 -->
- **[MUST]** User accounts are deactivated immediately after the user leaves (e.g. upon end of contract).
<!-- REQ 4.1.3-M5 -->
- **[MUST]** User accounts are reviewed regularly.
<!-- REQ 4.1.3-M6 -->
- **[MUST]** The log-on information is provided to the user in a secure manner.
<!-- REQ 4.1.3-M7 -->
- **[MUST]** A policy for handling log-on information is defined and implemented; the relevant aspects are taken into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S1 -->
- **[SHOULD]** A base account with minimal access rights and functionalities exists and is used.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S2 -->
- **[SHOULD]** Default accounts and passwords preconfigured by the manufacturer are deactivated (e.g. blocking or password change).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S3 -->
- **[SHOULD]** User accounts are created or authorised by the responsible body.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S4 -->
- **[SHOULD]** The creation of user accounts is subject to an approval process (four-eyes principle).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S5 -->
- **[SHOULD]** User accounts of service providers are deactivated after completion of their task.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S6 -->
- **[SHOULD]** Deadlines for deactivating and deleting user accounts are defined.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S7 -->
- **[SHOULD]** The use of default passwords is prevented technically.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S8 -->
- **[SHOULD]** In the case of strong authentication, the use of the medium (e.g. possession factor) is secure.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S9 -->
- **[SHOULD]** User accounts are reviewed regularly; this also includes accounts in customers' IT systems.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S10 -->
- **[SHOULD]** Interactive log-on for service accounts (technical accounts) is prevented technically.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.17-1 -->
- **[ISO A.5.17]** Allocation and management of authentication information is controlled by a suitable management process.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 4.1.3 -->
User accounts are managed via a defined lifecycle (joiner/mover/leaver) (see {{LINK:VA-03}}) uniquely personalised in the central directory ({{TOOL_IAM}}); triggers are {{TOOL_TICKET}} requests from HR/manager notifications. Accounts of leavers are deactivated without delay, accounts are reviewed regularly (including in customer systems), shared accounts are regulated. Log-on information is provided securely; default accounts/passwords are deactivated, base accounts with minimal rights are used, creation follows the four-eyes principle, and interactive log-on for technical accounts is prevented.
### 3.4 Access rights
<!-- FW:REF-START ORIG:(ISA 4.2.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.15, A.5.18, A.8.2, A.8.3, A.8.18{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 4.2.1-M1 -->
- **[MUST]** The requirements for managing access rights (authorisation) are determined and met; the relevant aspects are taken into account.
<!-- REQ 4.2.1-M2 -->
- **[MUST]** The access rights granted for normal and privileged user accounts as well as technical accounts are reviewed regularly, also in customers' IT systems.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S1 -->
- **[SHOULD]** Strategies for authorising access to information are prepared.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S2 -->
- **[SHOULD]** Authorisation roles are used.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S3 -->
- **[SHOULD]** Rights are granted according to the need-to-use principle and in line with role and/or area of responsibility.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S4 -->
- **[SHOULD]** Normal user accounts do not receive privileged access rights.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S5 -->
- **[SHOULD]** The user's access rights are updated after a change in their responsibilities.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.2.1-H1 -->
- **[HIGH]** The access rights are approved by the responsible internal information officer. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.2.1-V1 -->
- **[VERY HIGH]** Information is stored encrypted at content level (e.g. file level) to prevent unauthorised access (including by privileged users). Where encryption is not feasible, equivalent measures apply. (C)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.2.1-V2 -->
- **[VERY HIGH]** Existing access rights are reviewed at shorter intervals (e.g. quarterly). (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.15-1 -->
- **[ISO A.5.15]** Rules to control physical and logical access to information and assets are established and implemented on the basis of business and information security requirements.
<!-- REQ A.5.18-1 -->
- **[ISO A.5.18]** Access rights are provisioned, reviewed, modified and removed in accordance with the access control policy.
<!-- REQ A.8.2-1 -->
- **[ISO A.8.2]** The allocation and use of privileged access rights is restricted and closely managed.
<!-- REQ A.8.3-1 -->
- **[ISO A.8.3]** Access to information and application functions is restricted in accordance with the access control policy.
<!-- REQ A.8.18-1 -->
- **[ISO A.8.18]** The use of utility programs capable of overriding system and application controls is restricted and tightly controlled.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 4.2.1 -->
Access rights are granted according to the least-privilege principle (need-to-know/least privilege) on a role basis (RBAC) via the central directory ({{TOOL_IAM}}); request, technical review and approval take place in {{TOOL_TICKET}} (see {{LINK:VA-03}}). Rights are updated or revoked upon change/removal and recertified at least {{RECERT_FREQ}} (BL-IAM-05), also in customer systems; default accounts do not receive privileged rights.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.2.1-elev -->
Where the protection need is high, access rights are approved by the responsible internal information officer. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, information is stored with content-level encryption (protection also against privileged users) and access rights are reviewed at shorter intervals (e.g. quarterly).{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Technical implementation of IAM |
| Business units | Approval of authorisations |
| {{ROLE_ISB}} | Monitoring |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-03}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R02}}, {{LINK:R05}}, {{LINK:R10}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R09_Kryptografie-und-Uebertragungsrichtlinie.md
+156
View File
@@ -0,0 +1,156 @@
# Policy Cryptography and Transmission Policy
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs cryptographic procedures, key management and protection during information transmission. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Use of cryptographic procedures
<!-- FW:REF-START ORIG:(ISA 5.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.24{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.1.1-M1 -->
- **[MUST]** All cryptographic procedures used (e.g. encryption, signature, hash algorithms, protocols) provide the security required in the respective field of application according to a recognised industry standard, as far as legally possible.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.1-S1 -->
- **[SHOULD]** A concept for the use of cryptography is defined and implemented; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.1.1-H1 -->
- **[HIGH]** Requirements for key sovereignty (in particular in the case of external processing) are determined and met. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.24-1 -->
- **[ISO A.8.24]** Rules for the effective use of cryptography, including key management, are defined and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.1.1 -->
The permissible procedures and key lengths per BL-CRY-02 ({{CRYPTO_ALGO}}) correspond to the recognised industry standard and are prescribed; outdated procedures are prohibited. A cryptography concept is documented (see {{LINK:VA-07}}), and keys are securely managed throughout their lifecycle (BL-CRY-05).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.1.1-elev -->
Where the protection need is high, requirements for key sovereignty (in particular in the case of external processing) are determined and met.
{{/if}}
### 3.2 Protection during information transmission
<!-- FW:REF-START ORIG:(ISA 5.1.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.14{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.1.2-M1 -->
- **[MUST]** The network services used for transmitting information are identified and documented.
<!-- REQ 5.1.2-M2 -->
- **[MUST]** Policies and procedures in line with the classification requirements for the use of network services are defined and implemented.
<!-- REQ 5.1.2-M3 -->
- **[MUST]** Measures to protect transmitted content against unauthorised access are implemented.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S1 -->
- **[SHOULD]** Measures to ensure correct addressing and correct transmission of information are implemented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S2 -->
- **[SHOULD]** Electronic data exchange takes place using content or transport encryption in line with the respective classification.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S3 -->
- **[SHOULD]** Remote access connections to the organisation's network have appropriate security features; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.1.2-H1 -->
- **[HIGH]** Information is transmitted encrypted (at least transport encryption) or protected by equivalently effective measures. (C)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.1.2-V1 -->
- **[VERY HIGH]** Information is transmitted with content encryption. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.14-1 -->
- **[ISO A.5.14]** Rules, procedures and agreements for the secure transfer of information are established for all transfer channels in use.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.1.2 -->
The network services used are identified and documented in the network/network services register ({{LINK:REG-NET}}); policies/procedures in line with the classification are implemented. Information is protected during transmission in accordance with the protection need (at least {{TLS_MIN}}, BL-CRY-01), correct addressing is ensured and remote access is safeguarded; rules for email/file encryption are defined (BL-CRY-04, cryptography/key management see {{LINK:VA-07}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.1.2-elev -->
Where the protection need is high, information is transmitted at least transport-encrypted or protected equivalently; {{#if FLAG_VERY_HIGH_PROTECTION}}where the protection need is very high, content encryption is applied.{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Procedures/keys |
| {{ROLE_ISB}} | Permissible algorithms |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-07}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R08}}, {{LINK:R10}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R10_Betriebssicherheit.md
+598
View File
@@ -0,0 +1,598 @@
# Policy Operational Security
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs secure IT operations: change, environment separation, malware protection, logging, vulnerabilities, technical review, network security as well as data backup. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Change management (change)
<!-- FW:REF-START ORIG:(ISA 5.2.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.9, A.8.32{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.1-M1 -->
- **[MUST]** Information security requirements for changes to the organisation, business processes and IT systems are determined and met.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S1 -->
- **[SHOULD]** A formal approval procedure is established.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S2 -->
- **[SHOULD]** The possible effects of changes on information security are assessed.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S3 -->
- **[SHOULD]** Changes with an effect on information security are planned and tested.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S4 -->
- **[SHOULD]** Fallback procedures in the event of errors are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.1-H1 -->
- **[HIGH]** Compliance with the information security requirements is verified during and after the changes. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.9-1 -->
- **[ISO A.8.9]** Configurations of hardware, software, services and networks are established, documented, implemented, monitored and reviewed.
<!-- REQ A.8.32-1 -->
- **[ISO A.8.32]** Changes to information processing facilities and systems are subject to change management.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.1 -->
Changes go through a formal change procedure (see {{LINK:VA-04}}) with request, impact/risk assessment, planning, testing, approval, rollback plan and documentation in {{TOOL_TICKET}} (BL-OPS-09); information security requirements are determined and met.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.1-elev -->
Where the protection need is high, compliance with the information security requirements is verified during and after the change.
{{/if}}
### 3.2 Separation of development, test and production systems
<!-- FW:REF-START ORIG:(ISA 5.2.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.31{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.2-M1 -->
- **[MUST]** The IT systems have been subjected to a risk assessment to determine the need to separate them into development, test and production systems.
<!-- REQ 5.2.2-M2 -->
- **[MUST]** A segmentation is implemented on the basis of the results of the risk analysis.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.2-S1 -->
- **[SHOULD]** The requirements for development and test environments are determined and met; the relevant aspects are taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.31-1 -->
- **[ISO A.8.31]** Development, test and production environments are separated and protected.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.2 -->
On the basis of a risk assessment, development, test and production are operated separately and segmented; requirements for development/test environments are determined and met, and production data is used there only in anonymised/pseudonymised form.
### 3.3 Protection against malware
<!-- FW:REF-START ORIG:(ISA 5.2.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.7, A.8.23{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.3-M1 -->
- **[MUST]** Requirements for protection against malware are determined.
<!-- REQ 5.2.3-M2 -->
- **[MUST]** Technical and organisational measures for protection against malware are defined and implemented.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S1 -->
- **[SHOULD]** Unnecessary network services are deactivated.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S2 -->
- **[SHOULD]** Access to network services is limited to what is necessary through appropriate protective measures.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S3 -->
- **[SHOULD]** Protective software against malware is installed and updated automatically at regular intervals (e.g. virus scanner).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S4 -->
- **[SHOULD]** Received files and software are automatically checked for malware before execution (on-access scan).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S5 -->
- **[SHOULD]** The entire data stock of all systems is checked for malware regularly.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S6 -->
- **[SHOULD]** Data transmitted via central gateways (e.g. email, internet, external networks) is automatically checked by protective software.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S7 -->
- **[SHOULD]** Measures preventing protective software from being deactivated or modified by users are defined and implemented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S8 -->
- **[SHOULD]** For IT systems without protective software, alternative measures are implemented (e.g. special resilience, few services, no active users, network isolation).
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.7-1 -->
- **[ISO A.8.7]** Protection against malware is implemented and supported by appropriate user awareness.
<!-- REQ A.8.23-1 -->
- **[ISO A.8.23]** Access to external websites is managed to reduce exposure to malicious content.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.3 -->
Malware protection is implemented via {{TECH_MALWARE}} on all endpoints and servers (BL-OPS-03); signatures/engines update themselves {{MALWARE_UPDATE}}, on-access and regular full scans as well as gateway checks (email/internet) are active. Unnecessary network services are deactivated, access is limited, and deactivating the protective software is prevented; for systems without protective software, alternative measures apply (isolation).
### 3.4 Logging and evaluation
<!-- FW:REF-START ORIG:(ISA 5.2.4) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.15, A.8.16{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.4-M1 -->
- **[MUST]** Information security requirements for handling event logs are determined and met.
<!-- REQ 5.2.4-M2 -->
- **[MUST]** Security-relevant requirements for logging the activities of administrators and users are determined and met.
<!-- REQ 5.2.4-M3 -->
- **[MUST]** The IT systems used are assessed with regard to the need for logging.
<!-- REQ 5.2.4-M4 -->
- **[MUST]** When external IT services are used, information on the monitoring options is obtained and taken into account in the assessment.
<!-- REQ 5.2.4-M5 -->
- **[MUST]** Event logs are checked regularly for policy violations and conspicuous problems, in compliance with the permissible legal and organisational requirements.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S1 -->
- **[SHOULD]** A procedure for escalating relevant events to the responsible body is defined and established.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S2 -->
- **[SHOULD]** Event logs (content and metadata) are protected against modification (e.g. by a dedicated environment).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S3 -->
- **[SHOULD]** Appropriate monitoring and recording of all information-security-relevant actions in the network is established.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.4-H1 -->
- **[HIGH]** Security-relevant requirements for handling event logs, e.g. contractual requirements, are determined and implemented. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.4-H2 -->
- **[HIGH]** Events relating to the establishment and termination of remote access sessions (e.g. remote maintenance) are logged. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.4-V1 -->
- **[VERY HIGH]** Logging of every access to data with a very high protection need, as far as technically feasible and legally/organisationally permissible. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.15-1 -->
- **[ISO A.8.15]** Logs of activities, exceptions, faults and events are produced, stored, protected and analysed.
<!-- REQ A.8.16-1 -->
- **[ISO A.8.16]** Networks, systems and applications are monitored for anomalous behaviour and potential incidents are evaluated.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.4 -->
Security-relevant events (incl. administrator/user activities) are logged centrally via {{TECH_SIEM}} according to determined and assessed requirements and evaluated regularly for violations (BL-OPS-04); for external services, the monitoring options are taken into account. Logs are protected against tampering, retention {{LOG_RETENTION}}, and an escalation procedure is established (see {{LINK:VA-13}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.4-elev -->
Where the protection need is high, additional (e.g. contractual) logging requirements are implemented and remote access sessions are logged. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, every access to corresponding data is logged, as far as technically/legally permissible.{{/if}}
{{/if}}
### 3.5 Handling of vulnerabilities
<!-- FW:REF-START ORIG:(ISA 5.2.5) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.5{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.8{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.5-M1 -->
- **[MUST]** Information about technical vulnerabilities of the IT systems used is collected (e.g. manufacturer information, system audits, CVE database).
<!-- REQ 5.2.5-M2 -->
- **[MUST]** Potentially affected IT systems and software are identified and the risk caused by the vulnerability is assessed.
<!-- REQ 5.2.5-M3 -->
- **[MUST]** Risks arising from vulnerabilities are treated.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S1 -->
- **[SHOULD]** Appropriate patch management is defined and implemented (e.g. patch testing and installation).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S2 -->
- **[SHOULD]** Risk-mitigating measures are implemented where necessary.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S3 -->
- **[SHOULD]** The successful installation of patches is verified in a suitable manner.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.8-1 -->
- **[ISO A.8.8]** Information on technical vulnerabilities is obtained, exposure is evaluated and appropriate measures are taken.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.5 -->
Vulnerability information is collected (manufacturer information, CVE, scans BL-OPS-02), affected systems are identified, the risk is assessed and treated on a risk basis according to BL-OPS-01 via patch/change management (see {{LINK:VA-06}}) (critical {{PATCH_SLA_CRIT}}); the successful installation is verified and tracked in {{TOOL_TICKET}}, and risk-mitigating measures apply where necessary.
### 3.6 Technical review of IT systems
<!-- FW:REF-START ORIG:(ISA 5.2.6) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.6{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.34{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.6-M1 -->
- **[MUST]** Requirements for the review (audit) of IT systems or services are determined.
<!-- REQ 5.2.6-M2 -->
- **[MUST]** The scope of the system review is defined in good time.
<!-- REQ 5.2.6-M3 -->
- **[MUST]** System or service reviews are coordinated with the operators and users of the IT systems/services.
<!-- REQ 5.2.6-M4 -->
- **[MUST]** The results of system/service reviews are stored in a traceable manner and reported to the responsible management.
<!-- REQ 5.2.6-M5 -->
- **[MUST]** Measures are derived from the results and implemented within an appropriate period.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S1 -->
- **[SHOULD]** System and service reviews are planned taking possible security risks (e.g. disruptions) into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S2 -->
- **[SHOULD]** Regular system or service reviews are carried out; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S3 -->
- **[SHOULD]** Within an appropriate period after completion of the review, a report is prepared.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.6-H1 -->
- **[HIGH]** For critical IT systems/services, additional review requirements have been identified and are met (e.g. service-specific tests/tools and/or manual penetration tests, risk-based intervals). (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.6-V1 -->
- **[VERY HIGH]** IT systems and services are scanned regularly for vulnerabilities. For systems/services that cannot be scanned, suitable protective measures are to be implemented. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.34-1 -->
- **[ISO A.8.34]** Audit tests and similar activities on operational systems are planned and agreed to avoid disruption.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.6 -->
Requirements and scope of technical reviews are determined and coordinated with operators/users; systems are configured according to hardening requirements (BL-OPS-07, e.g. CIS benchmarks) and reviewed on a risk basis (see {{LINK:VA-06}}). Results are stored in a traceable manner, reported to management, and measures are implemented on time.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.6-elev -->
Where the protection need is high, additional reviews (penetration tests {{PENTEST_FREQ}}, BL-OPS-08) are carried out for critical systems. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, systems are scanned regularly for vulnerabilities, or systems that cannot be scanned are protected by suitable measures.{{/if}}
{{/if}}
### 3.7 Network security
<!-- FW:REF-START ORIG:(ISA 5.2.7) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.7{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.20, A.8.22{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.7-M1 -->
- **[MUST]** Requirements for the management and control of networks are determined and met.
<!-- REQ 5.2.7-M2 -->
- **[MUST]** Requirements for network segmentation are determined and met.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.7-S1 -->
- **[SHOULD]** Procedures for the management and control of networks are defined.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.7-S2 -->
- **[SHOULD]** For a risk-based network segmentation, the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.7-H1 -->
- **[HIGH]** Extended requirements for the management and control of networks are determined and implemented. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.20-1 -->
- **[ISO A.8.20]** Networks and network devices are secured, managed and controlled to protect information.
<!-- REQ A.8.22-1 -->
- **[ISO A.8.22]** Groups of information services, users and systems are segregated in networks.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.7 -->
The network is segmented on a risk basis according to the protection need (BL-NET-01), access-controlled and secured externally via a firewall (default deny, BL-NET-02); management/control procedures and an up-to-date network plan/segmentation concept are maintained in the network/network services register ({{LINK:REG-NET}}).{{#if FLAG_OT_USED}} Production/OT networks are separated from office networks and specially secured.{{/if}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.7-elev -->
Where the protection need is high, extended requirements for network management and control are determined and implemented.
{{/if}}
### 3.8 Data backup and recovery
<!-- FW:REF-START ORIG:(ISA 5.2.9) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.9{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.13{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.9-M1 -->
- **[MUST]** Backup concepts exist for relevant IT systems. Appropriate protective measures for the confidentiality, integrity and availability of the backups are taken into account.
<!-- REQ 5.2.9-M2 -->
- **[MUST]** Recovery concepts exist for relevant IT services.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.9-S1 -->
- **[SHOULD]** For each relevant IT service, a backup and recovery concept exists. Dependencies between IT services and the recovery sequence are taken into account.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.9-H1 -->
- **[HIGH]** Backup and recovery concepts are reviewed methodically at regular intervals. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.9-H2 -->
- **[HIGH]** The fundamental recoverability is taken into account and tested (e.g. sample tests, test systems). (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V1 -->
- **[VERY HIGH]** (Additional) backups are carried out via offline procedures, immutable backups or an isolated IAM solution. (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V2 -->
- **[VERY HIGH]** Recovery procedures are tested technically and methodically at regular intervals. (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V3 -->
- **[VERY HIGH]** Geographical redundancy is taken into account in backup and recovery concepts. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.13-1 -->
- **[ISO A.8.13]** Backup copies of information, software and systems are created in accordance with the backup concept and tested regularly.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.2.9 -->
Backup and recovery concepts for relevant IT services exist (protection of confidentiality/integrity/availability, dependencies and sequence taken into account); backups are performed according to the scheme {{BACKUP_SCHEME}} via {{TECH_BACKUP}} (BL-OPS-05), retention {{BACKUP_RETENTION}}, recovery regulated and tested (see {{LINK:VA-05}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.9-elev -->
Where the protection need is high, concepts are reviewed methodically and recoverability is tested. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, additional offline/immutable backups, methodical technical restore tests and geographical redundancy are carried out.{{/if}}
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Secure IT operations |
| {{ROLE_ISB}} | Monitoring |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-04}}, {{LINK:VA-05}}, {{LINK:VA-06}}, {{LINK:VA-13}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R04}}, {{LINK:R08}}, {{LINK:R11}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.9 Threat intelligence
*Requirement reference:* ISO/IEC 27001 A.5.7
**Requirement**
<!-- REQ A.5.7-1 -->
- **[ISO A.5.7]** Information on threats is collected and analysed to produce and use threat intelligence.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-THREATINTEL -->
Information on threats is obtained regularly from named sources ({{THREAT_INTEL_SOURCES}}) and evaluated by {{ROLE_IT_LEAD}} for relevance to the organisation's own systems and services. Relevant findings lead to actions in vulnerability and patch management ({{LINK:VA-06}}), to adjustments of monitoring ({{LINK:VA-13}}) or to a new risk assessment. Evaluation and resulting actions are documented in {{TOOL_TICKET}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.10 Documented operating procedures
*Requirement reference:* ISO/IEC 27001 A.5.37
**Requirement**
<!-- REQ A.5.37-1 -->
- **[ISO A.5.37]** Operating procedures for information processing facilities are documented and made available to the personnel concerned.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-BETRIEBSABLAEUFE -->
Operating procedures for information processing facilities are documented and accessible to the personnel who carry them out. They cover commissioning and configuration, operation and monitoring, backup, handling of faults, maintenance and decommissioning. The documentation is updated through change management (BL-OPS-09) whenever changes occur and is checked for currency at least {{POLICY_REVIEW_CYCLE}}. Responsible: {{ROLE_IT_LEAD}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.11 Capacity management
*Requirement reference:* ISO/IEC 27001 A.8.6
**Requirement**
<!-- REQ A.8.6-1 -->
- **[ISO A.8.6]** Resources are monitored and capacity is adjusted to current and expected demand.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-KAPAZITAET -->
The utilisation of the relevant resources — compute, memory, storage, network bandwidth, licences and staffing in IT operations — is monitored {{CAPACITY_REVIEW_FREQ}} (BL-OPS-11). Exceeded thresholds raise an alert; future demand is taken into account in projects and significant changes. Capacity constraints that affect the availability requirements are recorded and treated as a risk.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.12 Data leakage prevention
*Requirement reference:* ISO/IEC 27001 A.8.12
**Requirement**
<!-- REQ A.8.12-1 -->
- **[ISO A.8.12]** Measures to prevent data leakage are applied to systems, networks and devices that process sensitive information.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-DLP -->
For systems, networks and devices that process protected information, measures against unauthorised outflow are in place (BL-OPS-12); at least {{DLP_SCOPE}} are covered. The measures follow the classification ({{LINK:R02}}): rules for disclosure, control of transfer channels, restriction of removable media (BL-EP-03) as well as logging and analysis of conspicuous transfers (BL-OPS-04). Detected violations are handled as security events ({{LINK:VA-01}}); where analysis relates to individuals, co-determination rights are observed.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.13 Clock synchronisation
*Requirement reference:* ISO/IEC 27001 A.8.17
**Requirement**
<!-- REQ A.8.17-1 -->
- **[ISO A.8.17]** System clocks are synchronised to approved time sources.
**Implementation at {{ORG_NAME}}**
<!-- IMPL ISO-ZEITSYNC -->
The system clocks of all logging systems are synchronised to {{NTP_SOURCES}} (BL-OPS-10). Deviations are monitored and reported. A uniform time base and time zone is a prerequisite for the analysis of logs ({{LINK:VA-13}}) and for preserving evidence in the event of an incident.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md
+219
View File
@@ -0,0 +1,219 @@
# Policy Secure System Procurement and Development
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs information security in procurement and development, requirements for network services as well as return and secure deletion. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Security in procurement and development
<!-- FW:REF-START ORIG:(ISA 5.3.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.4, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.30, A.8.33{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.1-M1 -->
- **[MUST]** The information security requirements associated with the design and development of an IT service are determined and taken into account.
<!-- REQ 5.3.1-M2 -->
- **[MUST]** The information security requirements associated with the procurement or extension of IT services and components are determined and taken into account.
<!-- REQ 5.3.1-M3 -->
- **[MUST]** Information security requirements in connection with changes to developed IT services are taken into account.
<!-- REQ 5.3.1-M4 -->
- **[MUST]** System acceptance tests are carried out taking the information security requirements into account.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S1 -->
- **[SHOULD]** Requirement specifications are created; the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S2 -->
- **[SHOULD]** Requirement specifications are checked against the information security requirements.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S3 -->
- **[SHOULD]** The IT service is checked for compliance with the specifications before production use.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S4 -->
- **[SHOULD]** The use of production data for test purposes is avoided as far as possible (anonymisation/pseudonymisation where applicable); the relevant aspects are taken into account.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S5 -->
- **[SHOULD]** Test systems receive protective measures comparable to the production environment when production data is used for testing.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.3.1-V1 -->
- **[VERY HIGH]** The security of purpose-built or substantially adapted software is tested upon commissioning, upon substantial changes or regularly (e.g. penetration test). (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.4-1 -->
- **[ISO A.8.4]** Read and write access to source code, development tools and software libraries is appropriately managed.
<!-- REQ A.8.25-1 -->
- **[ISO A.8.25]** Rules for a secure development life cycle of software and systems are established and applied.
<!-- REQ A.8.26-1 -->
- **[ISO A.8.26]** Information security requirements are identified, specified and taken into account when developing or acquiring applications.
<!-- REQ A.8.27-1 -->
- **[ISO A.8.27]** Principles for engineering secure systems are established, documented and applied.
<!-- REQ A.8.28-1 -->
- **[ISO A.8.28]** Secure coding principles are applied to software development.
<!-- REQ A.8.29-1 -->
- **[ISO A.8.29]** Security testing is integrated into the development and acceptance process.
<!-- REQ A.8.30-1 -->
- **[ISO A.8.30]** Outsourced system development is directed, monitored and reviewed.
<!-- REQ A.8.33-1 -->
- **[ISO A.8.33]** Test information is selected, protected and managed with care.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.3.1 -->
Information security requirements are an integral part of the design, procurement, extension and modification of IT services (security by design); requirement specification, review and acceptance tests under security aspects are carried out following the procedure Secure Procurement/Development & Acceptance ({{LINK:VA-16}}); production deployment only after review in {{TOOL_TICKET}}. Production data in tests is avoided/anonymised, and test systems are appropriately protected.{{#if FLAG_DEV_INHOUSE}} For in-house development, secure coding requirements apply with code reviews and automated security tests (SAST/dependency scan) in accordance with {{LINK:VA-16}}.{{/if}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.3.1-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, the security of purpose-built or substantially adapted software is tested upon commissioning, upon substantial changes or regularly (penetration test).{{/if}}
{{/if}}
### 3.2 Requirements for network services
<!-- FW:REF-START ORIG:(ISA 5.3.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.21{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.2-M1 -->
- **[MUST]** Requirements for the information security of network services are determined and met.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S1 -->
- **[SHOULD]** A procedure for securing and using network services is defined and implemented.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S2 -->
- **[SHOULD]** The requirements are agreed in the form of SLAs.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S3 -->
- **[SHOULD]** Appropriate redundancy solutions are implemented.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.3.2-H1 -->
- **[HIGH]** Procedures for monitoring the quality of network traffic (e.g. traffic flow analyses, availability measurements) are defined and carried out. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.21-1 -->
- **[ISO A.8.21]** Security mechanisms, service levels and requirements for network services are identified, implemented and monitored.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.3.2 -->
For the network services used (internal/external), security requirements are determined, agreed in SLAs and implemented via a procedure; appropriate redundancies are in place.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.3.2-elev -->
Where the protection need is high, procedures for monitoring network traffic quality (traffic flow analyses, availability measurements) are defined and carried out.
{{/if}}
### 3.3 Return and secure deletion
<!-- FW:REF-START ORIG:(ISA 5.3.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.11, A.7.14, A.8.10{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.3-S1 -->
- **[SHOULD]** A description of the termination process is in place, adapted to changes and regulated contractually.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.11-1 -->
- **[ISO A.5.11]** Personnel and external users return all assets in their possession upon termination of employment or contract.
<!-- REQ A.7.14-1 -->
- **[ISO A.7.14]** Equipment containing storage media is securely sanitised before disposal or re-use.
<!-- REQ A.8.10-1 -->
- **[ISO A.8.10]** Information stored in systems and on media is deleted when no longer required.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.3.3 -->
Return and secure deletion/destruction of information and assets (upon end of contract, device decommissioning) are regulated according to BL-DEL-01, agreed contractually, adapted to changes and evidenced (deletion log).
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Procurement/development |
| {{ROLE_ISB}} | Security requirements |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R02}}, {{LINK:R10}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R12_Cloud-KI-und-externe-IT-Dienste.md
+117
View File
@@ -0,0 +1,117 @@
# Policy Cloud, AI and External IT Services
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs protection in outsourced/shared external IT services (cloud) as well as the use of AI/GenAI services. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Protection in shared external IT services
<!-- FW:REF-START ORIG:(ISA 5.3.4) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.23{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.4-M1 -->
- **[MUST]** An effective separation (e.g. tenant separation) prevents unauthorised users of other organisations from accessing one's own information.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.4-S1 -->
- **[SHOULD]** The provider's separation concept is documented and adapted to changes; the relevant aspects are taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.23-1 -->
- **[ISO A.5.23]** Processes for acquisition, use, management and exit of cloud services are established in line with the information security requirements.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.3.4 -->
For shared external IT services, effective tenant separation is required and contractually assured; the provider's separation concept is documented and updated upon changes.{{#if FLAG_CLOUD_USED}} Cloud services are assessed before use (protection need, data location/EU, encryption, exit) and approved by {{ROLE_ISB}}; the approvals are maintained in the register of external IT/cloud/AI services ({{LINK:REG-EXT-SERVICES}}) (see {{LINK:VA-11}}).{{/if}}
{{#if FLAG_AI_USED}}
### 3.2 Use of AI/GenAI services (supplement R12, not ISA)
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.4-KI-M1 -->
- **[MUST]** The use of AI/GenAI services is regulated; only approved services are used.
<!-- REQ 5.3.4-KI-M2 -->
- **[MUST]** The input of confidential or personal information into non-approved AI services is prohibited; the permissible data classes per service are defined.
<!-- REQ 5.3.4-KI-M3 -->
- **[MUST]** For approved AI services, it is clarified and contractually ensured that inputs are not used for training or passed on.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.4-KI-S1 -->
- **[SHOULD]** Results of AI services are reviewed before business-critical use (human in the loop); the use of AI is documented and regulatory requirements (e.g. EU AI Act) are taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 5.3.4-KI -->
The use of AI/GenAI services is regulated; only services approved by {{ROLE_ISB}} (maintained in the register of external IT/cloud/AI services {{LINK:REG-EXT-SERVICES}}) may be used (see {{LINK:VA-11}}). The permissible data classes per service are defined, and the input of confidential/personal data into non-approved services is prohibited; upon approval, it is contractually ensured that inputs are not used for training or passed on. AI results are reviewed before critical use (human in the loop), the use is documented and the EU AI Act is taken into account.
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Approval/steering |
| {{ROLE_IT_LEAD}} | Technical safeguarding |
| Business units | Use of approved services |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-11}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R09}}, {{LINK:R11}}, {{LINK:R13}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R13_Lieferanten-und-Dienstleistersteuerung.md
+250
View File
@@ -0,0 +1,250 @@
# Policy Supplier and Service Provider Management
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs ensuring information security at suppliers, confidentiality agreements and the delineation of responsibilities. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Information security at suppliers
<!-- FW:REF-START ORIG:(ISA 6.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.19, A.5.22{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.1-M1 -->
- **[MUST]** Contractors and partners are subjected to a security risk assessment.
<!-- REQ 6.1.1-M2 -->
- **[MUST]** An appropriate level of information security is ensured through contractual agreements with contractors and partners.
<!-- REQ 6.1.1-M3 -->
- **[MUST]** Where applicable, contractual agreements with clients/customers are passed on to contractors and partners.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.1-S1 -->
- **[SHOULD]** Contractors and partners are contractually obliged to pass on requirements for an appropriate level of information security to their subcontractors.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.1-S2 -->
- **[SHOULD]** Performance reports and documents from contractors and partners are reviewed.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H1 -->
- **[HIGH]** It is demonstrated that the supplier's level of information security is appropriate to the protection need (e.g. reviewed questionnaire/self-disclosure, attestation, certificate, supplier audit). (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H2 -->
- **[HIGH]** The degree of fulfilment of the required evidence by the supplier is documented, reviewed and monitored regularly and upon changes. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H3 -->
- **[HIGH]** The supplier's compliance with contractual agreements is checked, documented, reviewed and monitored regularly and upon changes. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 6.1.1-V1 -->
- **[VERY HIGH]** The appropriate level of information security should be demonstrated by a third-party audit (an appropriate TISAX label or similar) or an appropriate supplier audit. Without an audit, management must make a risk-based decision to continue; evidence of this decision exists. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 6.1.1-V2 -->
- **[VERY HIGH]** Contractual obligations towards customers regarding transparency of supply chain risks are fulfilled. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.19-1 -->
- **[ISO A.5.19]** Processes to manage the information security risks arising from supplier relationships are defined and implemented.
<!-- REQ A.5.22-1 -->
- **[ISO A.5.22]** The information security of supplier services is monitored and reviewed regularly, and changes are managed.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 6.1.1 -->
Contractors/partners are subjected to a security risk assessment (BL-SUP-01) and contractually obliged to an appropriate level of information security (incl. passing on to subcontractors and customer requirements); the supplier register is maintained in the ISMS tool ({{TOOL_NAME}}), and performance reports are reviewed (see {{LINK:VA-10}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 6.1.1-elev -->
Where the protection need is high, the supplier's level of security is demonstrated (self-disclosure/attestation/certificate/audit) and compliance is documented and monitored regularly and upon changes. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, the evidence is provided via a third-party audit (TISAX or similar) or a documented risk-based management decision; transparency obligations regarding supply chain risks are fulfilled.{{/if}}
{{/if}}
### 3.2 Confidentiality agreements
<!-- FW:REF-START ORIG:(ISA 6.1.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.20{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.2-M1 -->
- **[MUST]** The confidentiality requirements are determined and met.
<!-- REQ 6.1.2-M2 -->
- **[MUST]** Requirements and procedures for applying confidentiality agreements are known to all persons who pass on information requiring protection.
<!-- REQ 6.1.2-M3 -->
- **[MUST]** Valid confidentiality agreements are concluded before information requiring protection is passed on.
<!-- REQ 6.1.2-M4 -->
- **[MUST]** The requirements and procedures for using confidentiality agreements and for handling information requiring protection are reviewed regularly.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S1 -->
- **[SHOULD]** Templates for confidentiality agreements are available and checked for legal applicability.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S2 -->
- **[SHOULD]** Confidentiality agreements cover the persons/organisations involved, the type of information, the subject matter, the period of validity and the responsibilities of the obligated party.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S3 -->
- **[SHOULD]** Confidentiality agreements contain provisions for handling information requiring protection beyond the contractual relationship.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S4 -->
- **[SHOULD]** Ways to demonstrate compliance (e.g. review by independent third parties or audit rights) are defined.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S5 -->
- **[SHOULD]** A process for monitoring the period of validity of temporary confidentiality agreements and for timely renewal is defined and implemented.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.20-1 -->
- **[ISO A.5.20]** Relevant information security requirements are agreed with each supplier and recorded contractually.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 6.1.2 -->
Confidentiality requirements are determined and known; before information requiring protection is passed on, valid NDAs based on reviewed standard templates (process see {{LINK:VA-10}}) (with parties, type of information, subject matter, validity, responsibilities and post-contractual provisions) are concluded and stored in the ISMS tool. Requirements/procedures and periods of validity are monitored regularly, and ways to demonstrate compliance are defined.
### 3.3 Delineation of responsibilities
<!-- FW:REF-START ORIG:(ISA 6.1.3) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.21{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.3-M1 -->
- **[MUST]** The IT services concerned are identified.
<!-- REQ 6.1.3-M2 -->
- **[MUST]** The security requirements relevant to the IT service are determined.
<!-- REQ 6.1.3-M3 -->
- **[MUST]** The organisation responsible for implementing the requirement is defined and aware of its responsibility.
<!-- REQ 6.1.3-M4 -->
- **[MUST]** Mechanisms for shared responsibilities are specified and implemented.
<!-- REQ 6.1.3-M5 -->
- **[MUST]** The responsible organisation fulfils its respective responsibilities.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.3-S1 -->
- **[SHOULD]** For IT services, the configuration is designed, implemented and documented on the basis of the necessary security requirements.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.3-S2 -->
- **[SHOULD]** The responsible personnel is appropriately trained.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H1 -->
- **[HIGH]** A list of the IT services concerned and the respective responsible IT service providers exists. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H2 -->
- **[HIGH]** The applicability of the ISA controls has been assessed and documented. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H3 -->
- **[HIGH]** The service configuration is included in the regular security assessments. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H4 -->
- **[HIGH]** It is demonstrated that the IT service providers fulfil their responsibility. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H5 -->
- **[HIGH]** The integration into local protective measures (e.g. secure authentication mechanisms) is established and documented. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.21-1 -->
- **[ISO A.5.21]** Processes to manage information security risks in the ICT product and service supply chain are defined and implemented.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 6.1.3 -->
The IT services concerned and their security requirements are identified; responsibilities between the organisation and external IT service providers (incl. mechanisms for shared responsibility) are defined, known and fulfilled (see {{LINK:VA-10}}); the IT services and service providers concerned are maintained in the register of external IT/cloud/AI services ({{LINK:REG-EXT-SERVICES}}). The configuration is implemented on a requirements basis and documented, and the personnel is trained.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 6.1.3-elev -->
Where the protection need is high, a list of the IT services and responsible service providers exists, the applicability of the ISA controls is assessed/documented, the service configuration is part of regular security assessments, the fulfilment of responsibility is demonstrated, and the integration into local protective measures is documented.
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Supplier management |
| Procurement | Contractual integration |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Associated procedures: {{LINK:VA-10}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:R01}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/richtlinien/R14_Compliance-und-Datenschutz.md
+129
View File
@@ -0,0 +1,129 @@
# Policy Compliance and Data Protection
| Document information | Value |
|-----------------------|------|
| Document type | Policy |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Responsible | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Purpose
This policy governs compliance with regulatory/contractual requirements as well as the protection of personal data. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
## 2. Scope
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Requirements and implementation
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
### 3.1 Regulatory and contractual compliance
<!-- FW:REF-START ORIG:(ISA 7.1.1) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 7.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.31, A.5.32, A.5.33{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 7.1.1-M1 -->
- **[MUST]** Legal, regulatory and contractual requirements relevant to information security are determined regularly.
<!-- REQ 7.1.1-M2 -->
- **[MUST]** Policies for complying with the requirements are defined, implemented and communicated to the responsible persons.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 7.1.1-S1 -->
- **[SHOULD]** The integrity of records in accordance with legal, regulatory and contractual requirements as well as business requirements is taken into account.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.31-1 -->
- **[ISO A.5.31]** Legal, statutory, regulatory and contractual information security requirements are identified, documented and kept up to date.
<!-- REQ A.5.32-1 -->
- **[ISO A.5.32]** Appropriate procedures to protect intellectual property rights are implemented.
<!-- REQ A.5.33-1 -->
- **[ISO A.5.33]** Records are protected against loss, destruction, falsification, unauthorised access and unauthorised release.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 7.1.1 -->
Relevant legal, regulatory and contractual requirements are determined regularly and recorded in a compliance/legal register in the ISMS tool ({{TOOL_NAME}}); policies for compliance are defined, implemented and communicated to the responsible persons, and the integrity of records is taken into account.
{{#if FLAG_PERSONAL_DATA}}
### 3.2 Protection of personal data
<!-- FW:REF-START ORIG:(ISA 7.1.2) -->
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 7.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.34{{/if}}
<!-- FW:REF-END -->
**Requirement**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
<!-- REQ 7.1.2-M1 -->
- **[MUST]** Legal and contractual information security requirements for procedures and processes when processing personal data are determined.
<!-- REQ 7.1.2-M2 -->
- **[MUST]** Provisions for complying with legal and contractual requirements for the protection of personal data are defined and known to the persons involved.
<!-- REQ 7.1.2-M3 -->
- **[MUST]** Processes and procedures for protecting personal data are taken into account in the information security management system.
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.34-1 -->
- **[ISO A.5.34]** Requirements for the protection of personally identifiable information are identified and met in accordance with applicable obligations.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Implementation at {{ORG_NAME}}**
<!-- IMPL 7.1.2 -->
Legal and contractual requirements for the processing of personal data (GDPR) are determined; provisions are defined, known to those involved and taken into account in the ISMS. {{ROLE_DPO}} is involved, the record of processing activities is maintained in the ISMS tool ({{TOOL_NAME}}), and TOMs and deletion concepts (BL-DEL-01) are regulated; legal register review, deletion periods and data subject rights are processed following the data protection/compliance maintenance procedure ({{LINK:VA-18}}).
{{/if}}
## 4. Binding nature
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_ISB}}.
## 5. Roles and responsibilities
| Role | Responsibility in this policy |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Compliance register |
| {{ROLE_DPO}} | Data protection |
## 6. Review and update
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_ISB}} and approved by {{ROLE_MANAGEMENT}}.
## 7. Evidence
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
## 8. Related documents
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
- Evidence register: {{LINK:NACHWEISREGISTER}}
- Further: {{LINK:L00}}, {{LINK:R03}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/variables.schema.json
+379
View File
@@ -0,0 +1,379 @@
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ISMS Template Package v2 – Wizard Variables (VDA ISA 2027 / Information Security)",
"description": "Single source of truth for all wizard variables. Convention: UPPER_SNAKE_CASE, placeholder {{NAME}}. Feature flags control {{#if FLAG_X}} blocks. The developer generates the wizard inputs from this schema.",
"version": "2.0",
"type": "object",
"properties": {
"ORG_NAME": {
"type": "string",
"title": "Organisation (full name)",
"example": "Example Ltd"
},
"ORG_SHORT": {
"type": "string",
"title": "Organisation (short name)",
"example": "Example"
},
"ISMS_SCOPE": {
"type": "string",
"title": "Scope (short label)",
"example": "IT & Development, North Plant"
},
"ISMS_SCOPE_DESCRIPTION": {
"type": "string",
"title": "Scope (description)"
},
"ROLE_MANAGEMENT": {
"type": "string",
"title": "Top management",
"default": "Management"
},
"ROLE_ISB": {
"type": "string",
"title": "Information Security Officer / CISO",
"default": "Information Security Officer (ISO)"
},
"ROLE_IT_LEAD": {
"type": "string",
"title": "IT management",
"default": "IT management"
},
"ROLE_HR_LEAD": {
"type": "string",
"title": "HR management",
"default": "HR management"
},
"ROLE_DPO": {
"type": "string",
"title": "Data Protection Officer",
"default": "Data Protection Officer (DPO)"
},
"DOC_VERSION": {
"type": "string",
"title": "Version",
"default": "1.0"
},
"DOC_DATE": {
"type": "string",
"title": "Date",
"format": "date"
},
"DOC_STATUS": {
"type": "string",
"title": "Status",
"enum": [
"Draft",
"In review",
"Approved"
],
"default": "Draft"
},
"TOOL_NAME": {
"type": "string",
"title": "Name of the ISMS tool",
"default": "ISMS tool"
},
"REVIEW_CYCLE": {
"type": "string",
"title": "Review cycle (free text)",
"default": "annually"
},
"TECH_MFA": {
"type": "string",
"title": "MFA solution",
"default": "the MFA solution in use"
},
"TECH_MALWARE": {
"type": "string",
"title": "Malware protection solution",
"default": "the endpoint protection solution in use"
},
"TECH_BACKUP": {
"type": "string",
"title": "Backup solution",
"default": "the backup solution in use"
},
"TECH_SIEM": {
"type": "string",
"title": "Logging/SIEM solution",
"default": "the central logging"
},
"TECH_MDM": {
"type": "string",
"title": "MDM solution",
"default": "the MDM in use"
},
"TECH_VPN": {
"type": "string",
"title": "VPN/remote access solution",
"default": "VPN"
},
"TECH_CRYPTO": {
"type": "string",
"title": "Cryptography requirement/standard",
"default": "current BSI/industry recommendations"
},
"TOOL_TICKET": {
"type": "string",
"title": "Ticket/workflow system (documentation location)",
"default": "ticketing system"
},
"TOOL_IAM": {
"type": "string",
"title": "Directory/IAM system",
"default": "Entra ID / Active Directory"
},
"PW_MIN_LENGTH": {
"type": "string",
"title": "Minimum password length (BL-IAM-01)",
"default": "12"
},
"PW_COMPLEXITY": {
"type": "string",
"title": "Password complexity (BL-IAM-01)",
"default": "complexity of at least 3 of 4 character categories"
},
"PW_ROTATION": {
"type": "string",
"title": "Password rotation (BL-IAM-01)",
"default": "no fixed forced rotation, change on an ad-hoc basis upon suspicion"
},
"MFA_SCOPE": {
"type": "string",
"title": "MFA scope (BL-IAM-02)",
"default": "all remote access, administrative access and cloud services"
},
"SESSION_TIMEOUT": {
"type": "string",
"title": "Session timeout (BL-IAM-03)",
"default": "15 min inactivity (privileged), 8 hours (standard)"
},
"ACCOUNT_LOCKOUT": {
"type": "string",
"title": "Account lockout (BL-IAM-04)",
"default": "temporary lock after 10 failed attempts"
},
"RECERT_FREQ": {
"type": "string",
"title": "Recertification (BL-IAM-05)",
"default": "semi-annually"
},
"TLS_MIN": {
"type": "string",
"title": "Minimum TLS (BL-CRY-01)",
"default": "TLS 1.2 (recommendation TLS 1.3)"
},
"CRYPTO_ALGO": {
"type": "string",
"title": "Permissible algorithms (BL-CRY-02)",
"default": "AES-256, RSA ≥ 3072 / ECC ≥ 256, SHA-256 or stronger"
},
"PATCH_SLA_CRIT": {
"type": "string",
"title": "Patch SLA critical (BL-OPS-01)",
"default": "within 72 hours"
},
"PATCH_SLA_HIGH": {
"type": "string",
"title": "Patch SLA high (BL-OPS-01)",
"default": "within 14 days"
},
"PATCH_SLA_STD": {
"type": "string",
"title": "Patch SLA standard (BL-OPS-01)",
"default": "in the regular monthly patch cycle"
},
"VULN_SCAN_FREQ": {
"type": "string",
"title": "Vulnerability scan (BL-OPS-02)",
"default": "monthly"
},
"MALWARE_UPDATE": {
"type": "string",
"title": "Malware update (BL-OPS-03)",
"default": "automatically several times a day"
},
"LOG_RETENTION": {
"type": "string",
"title": "Log retention (BL-OPS-04)",
"default": "90 days, up to 12 months depending on risk"
},
"BACKUP_SCHEME": {
"type": "string",
"title": "Backup scheme (BL-OPS-05)",
"default": "3-2-1 (3 copies, 2 media, 1 offline/offsite)"
},
"BACKUP_RETENTION": {
"type": "string",
"title": "Backup retention (BL-OPS-05)",
"default": "daily 30 days, monthly 12 months"
},
"BACKUP_TEST_FREQ": {
"type": "string",
"title": "Recovery test (BL-OPS-06)",
"default": "annually"
},
"PENTEST_FREQ": {
"type": "string",
"title": "Penetration test (BL-OPS-08)",
"default": "annually"
},
"FLAG_INCLUDE_SHOULD": {
"type": "boolean",
"title": "Include SHOULD requirements (maturity level 3 = true)",
"default": true
},
"FLAG_HIGH_PROTECTION": {
"type": "boolean",
"title": "Include additional requirements for HIGH protection need",
"default": false
},
"FLAG_VERY_HIGH_PROTECTION": {
"type": "boolean",
"title": "Include additional requirements for VERY HIGH protection need",
"default": false
},
"FLAG_ELEVATED_PROTECTION": {
"type": "boolean",
"title": "Derived: HIGH OR VERY_HIGH active (set by the wizard = FLAG_HIGH_PROTECTION || FLAG_VERY_HIGH_PROTECTION)",
"default": false
},
"FLAG_CLOUD_USED": {
"type": "boolean",
"title": "Cloud services in use",
"default": true
},
"FLAG_AI_USED": {
"type": "boolean",
"title": "AI/GenAI services in use",
"default": true
},
"FLAG_OT_USED": {
"type": "boolean",
"title": "Production/OT environment present",
"default": false
},
"FLAG_DEV_INHOUSE": {
"type": "boolean",
"title": "In-house software development",
"default": false
},
"FLAG_MOBILE_WORK": {
"type": "boolean",
"title": "Mobile working / home office permitted",
"default": true
},
"FLAG_MOBILE_DEVICES": {
"type": "boolean",
"title": "Mobile devices / data media in use",
"default": true
},
"FLAG_CRYPTO_PKI": {
"type": "boolean",
"title": "Own PKI / certificate management",
"default": false
},
"FLAG_EXTERNAL_IT": {
"type": "boolean",
"title": "External IT service providers used",
"default": true
},
"FLAG_PERSONAL_DATA": {
"type": "boolean",
"title": "Processing of personal data",
"default": true
},
"FLAG_CUSTOMER_SYSTEMS": {
"type": "boolean",
"title": "Access to customer systems (e.g. OEM)",
"default": false
},
"FLAG_PROTOTYPE_PROTECTION": {
"type": "boolean",
"title": "Assessment objective prototype protection active (chapter 8.x)",
"default": false
},
"FLAG_ISB_INTERNAL": {
"type": "boolean",
"title": "ISO staffed internally",
"default": true
},
"FLAG_ISB_EXTERNAL": {
"type": "boolean",
"title": "ISO staffed externally (external service provider)",
"default": false
},
"FLAG_FW_TISAX": {
"type": "boolean",
"title": "Framework: apply TISAX / VDA ISA",
"default": true
},
"FLAG_FW_ISO27001": {
"type": "boolean",
"title": "Framework: apply ISO/IEC 27001",
"default": false
},
"POLICY_REVIEW_CYCLE": {
"type": "string",
"title": "Review cycle for the policy and thematic policies",
"example": "annually",
"default": "annually"
},
"MGMT_REVIEW_CYCLE": {
"type": "string",
"title": "Management review interval",
"example": "annually",
"default": "annually"
},
"RISK_REVIEW_CYCLE": {
"type": "string",
"title": "Risk assessment interval",
"example": "annually",
"default": "annually"
},
"RECORDS_RETENTION": {
"type": "string",
"title": "Retention of superseded document versions",
"example": "3 years",
"default": "3 years"
},
"AUTHORITY_CONTACTS": {
"type": "string",
"title": "Relevant authorities and reporting bodies",
"example": "data protection authority, police, national CERT",
"default": "data protection authority, police, national CERT"
},
"THREAT_INTEL_SOURCES": {
"type": "string",
"title": "Sources of threat intelligence",
"example": "national CERT advisories, vendor bulletins, CVE feeds",
"default": "national CERT advisories, vendor bulletins, CVE feeds"
},
"CAPACITY_REVIEW_FREQ": {
"type": "string",
"title": "Capacity monitoring interval",
"example": "monthly",
"default": "monthly"
},
"NTP_SOURCES": {
"type": "string",
"title": "Approved time sources",
"example": "two independent, trusted NTP sources",
"default": "two independent, trusted NTP sources"
},
"DLP_SCOPE": {
"type": "string",
"title": "Channels covered against data leakage",
"example": "e-mail, removable media, cloud storage",
"default": "e-mail, removable media, cloud storage"
}
},
"required": [
"ORG_NAME",
"ISMS_SCOPE",
"ISMS_SCOPE_DESCRIPTION",
"DOC_VERSION",
"DOC_DATE"
]
}
seed/isms-vorlagenpaket-v2-en/verfahren/VA-01_Incident-Response-und-Meldeverfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Incident Response and Reporting Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-01) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.6.1-M1, 1.6.1-M2, 1.6.2-M1, 1.6.2-M2, 1.6.2-S1, 1.6.2-S2, A.5.24-1, A.5.25-1, A.5.26-1, A.5.27-1, A.5.28-1, A.6.8-1 | POLICY R04 -->
## 1. Purpose
This procedure governs the reporting, assessment, handling and follow-up of information security incidents. It operationalises the associated policy ({{LINK:R04}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Reporting of a security event (employees, technology/monitoring, external parties) via the defined reporting path.
## 4. Inputs
- Report/alert with a brief description
- Affected systems/information (asset inventory)
- Classification/protection need
## 5. Process
1. Report the event: record the report via {{TOOL_TICKET}} or email to {{ROLE_ISB}}.
2. Triage & classification: determine relevance, severity and category.
3. Containment: initiate immediate measures to limit the damage.
4. Remediation & recovery: eliminate the cause, restore normal operations.
5. Check reporting obligations: customers/OEM, authorities, and for personal data {{ROLE_DPO}} (72-hour deadline).
6. Documentation & lessons learned: close the incident, derive improvement measures.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Report the event | Reporting person | {{ROLE_ISB}} | - | - |
| 2 | Triage & classification | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Containment | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} |
| 4 | Remediation & recovery | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 5 | Check reporting obligations | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | {{ROLE_DPO}} | - |
| 6 | Documentation & lessons learned | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | {{ROLE_MANAGEMENT}} |
## 7. Result & evidence
Documented, closed incident in {{TOOL_TICKET}}; derived measures in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Time to detect/acknowledge
- Time to resolve
- Share of reports made on time
## 9. Related documents
- Associated policy: {{LINK:R04}}
- {{LINK:VA-02}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-02_IT-Notfall-und-Wiederanlaufverfahren.md
+72
View File
@@ -0,0 +1,72 @@
# IT Emergency and Recovery Procedure (BCM)
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-02) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.6.3-M1, 1.6.3-S1, 5.2.8-M1, 5.2.8-S1, A.5.29-1, A.5.30-1, A.8.14-1 | POLICY R04 -->
## 1. Purpose
This procedure governs the maintenance and recovery of critical IT services in the event of failure or crisis. It operationalises the associated policy ({{LINK:R04}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Failure of critical IT services, emergency or crisis (escalation from VA-01).
## 4. Inputs
- List of critical IT services with RTO/RPO
- Recovery plans
- Backup status (VA-05)
## 5. Process
1. Identify & classify the emergency: assess the extent, convene the crisis team if necessary.
2. Activate communication: inform internal/external stakeholders.
3. Prioritise recovery: order services according to RTO/RPO.
4. Perform recovery: restore systems/data from backup (VA-05).
5. Confirm & document the return to normal operations.
6. Follow-up & test update: update the plan, exercise {{BACKUP_TEST_FREQ}}.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Identify & classify the emergency | {{ROLE_IT_LEAD}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 2 | Activate communication | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | - | Employees |
| 3 | Prioritise recovery | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Perform recovery | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Confirm return to normal operations & | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | {{ROLE_MANAGEMENT}} |
| 6 | Follow-up & test update | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Recovered services; documented emergency/test in the ISMS tool ({{TOOL_NAME}}); updated recovery plans. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Adherence to RTO/RPO
- Success rate of recovery tests
- Up-to-dateness of the emergency plans
## 9. Related documents
- Associated policy: {{LINK:R04}}
- {{LINK:VA-01}}
- {{LINK:VA-05}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-03_Berechtigungsverfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Authorisation Procedure (Joiner/Mover/Leaver and Recertification)
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-03) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 4.1.1-S1, 4.1.3-M1, 4.2.1-M1, 4.2.1-M2, 4.2.1-S1, A.5.15-1, A.5.16-1, A.5.17-1, A.5.18-1, A.8.18-1, A.8.2-1, A.8.3-1, A.8.5-1 | POLICY R08 -->
## 1. Purpose
This procedure governs the request, approval, modification, revocation and regular review of access rights. It operationalises the associated policy ({{LINK:R08}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Joining, role change or leaving of a person; authorisation request; due recertification.
## 4. Inputs
- HR notification
- Role/rights catalogue (RBAC)
- Existing authorisations from the central directory ({{TOOL_IAM}})
## 5. Process
1. Record the request: request access/right in {{TOOL_TICKET}} (joiner/mover).
2. Business approval: check the necessity according to the least-privilege principle and approve.
3. Implementation: set rights on a role basis in the central directory ({{TOOL_IAM}}).
4. Leaver/change: upon leaving/change, revoke/adjust rights without delay.
5. Recertification ({{RECERT_FREQ}}, BL-IAM-05): owners confirm/revoke rights.
6. Privileged accounts: review and log separately (BL-IAM-06).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Record the request | Manager/business unit | {{ROLE_IT_LEAD}} | - | - |
| 2 | Business approval | Business unit/data owner | Business unit/data owner | {{ROLE_ISB}} | - |
| 3 | Implementation | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | Requester |
| 4 | Leaver/change | {{ROLE_IT_LEAD}} | {{ROLE_HR_LEAD}} | - | - |
| 5 | Recertification ({{RECERT_FREQ}}, BL-IAM-05) | Business unit/data owner | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 6 | Privileged accounts | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Documented requests/approvals in {{TOOL_TICKET}}; current authorisation status in the central directory ({{TOOL_IAM}}); recertification evidence. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of leaver rights revoked on time
- Recertification rate
- Number of orphaned/privileged accounts
## 9. Related documents
- Associated policy: {{LINK:R08}}
- {{LINK:VA-01}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-04_Change-und-Patch-Management-Verfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Change and Patch Management Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-04) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.1-M1, 5.2.5-M1, A.7.13-1, A.8.19-1, A.8.32-1, A.8.9-1 | POLICY R10 -->
## 1. Purpose
This procedure governs planned changes to IT systems as well as the risk-oriented installation of patches. It operationalises the associated policy ({{LINK:R10}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Need for change, available patch or identified vulnerability (VA-06).
## 4. Inputs
- Change/patch request
- Risk assessment
- Patch SLA (BL-OPS-01)
## 5. Process
1. Request & classify the change (standard/normal/emergency) in {{TOOL_TICKET}}.
2. Risk/impact assessment incl. rollback plan.
3. Approval by CAB/responsible role.
4. Test in a separate environment (BL-OPS, R10).
5. Implementation in production in accordance with the patch SLA (critical {{PATCH_SLA_CRIT}}).
6. Verification & documentation of the result in {{TOOL_TICKET}}.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Request & classify the change | Requester | {{ROLE_IT_LEAD}} | - | - |
| 2 | Risk/impact assessment incl. rollback | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 3 | Approval by CAB/responsible role | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Test in a separate environment | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Implementation in production per patch SLA | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | Affected parties |
| 6 | Verification & documentation of the result | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Documented, approved and verified change/patch in {{TOOL_TICKET}}. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Patch compliance per criticality
- Share of successful changes (without rollback)
- Lead time of critical patches
## 9. Related documents
- Associated policy: {{LINK:R10}}
- {{LINK:VA-06}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-05_Backup-und-Restore-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Backup and Restore Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-05) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.9-M1, 5.2.9-M2, 5.2.9-S1, A.8.13-1 | POLICY R10 -->
## 1. Purpose
This procedure governs data backup, retention and recovery according to the {{BACKUP_SCHEME}} scheme. It operationalises the associated policy ({{LINK:R10}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Regular backup run; recovery need; scheduled restore test.
## 4. Inputs
- Backup plan per system
- Classification/RPO
- Backup targets ({{TECH_BACKUP}})
## 5. Process
1. Perform backup: automated backups in accordance with {{BACKUP_SCHEME}} (BL-OPS-05).
2. Monitoring: check success/failure, track failed runs ({{TOOL_TICKET}}).
3. Protection & offsite storage: 1 copy offline/immutable, retention {{BACKUP_RETENTION}}.
4. Process restore request (on demand/emergency, VA-02).
5. Perform & document recovery test ({{BACKUP_TEST_FREQ}}, BL-OPS-06).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Perform backup | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Monitoring | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 3 | Protection & offsite storage | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Process restore request (on demand) | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | Requester | - |
| 5 | Recovery test ({{BACKUP_TEST_FREQ}}) | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Logged backups; documented restore tests; evidence in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Backup success rate
- Success rate of restore tests
- Adherence to RPO
## 9. Related documents
- Associated policy: {{LINK:R10}}
- {{LINK:VA-02}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-06_Schwachstellenmanagement-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Vulnerability Management Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-06) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.5-M1, 5.2.5-S1, 5.2.6-M1, A.8.8-1 | POLICY R10 -->
## 1. Purpose
This procedure governs the detection, assessment, treatment and technical review of vulnerabilities. It operationalises the associated policy ({{LINK:R10}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Regular scan ({{VULN_SCAN_FREQ}}), security advisory/CVE, penetration test ({{PENTEST_FREQ}}).
## 4. Inputs
- Scan/test reports
- Asset inventory & criticality
- Patch SLA (BL-OPS-01)
## 5. Process
1. Identification: evaluate vulnerability scan {{VULN_SCAN_FREQ}} (BL-OPS-02) and advisories.
2. Assessment & prioritisation according to criticality and exposure.
3. Initiate treatment: patch/change (VA-04) or compensating measure.
4. Technical review: hardening (BL-OPS-07) and penetration tests ({{PENTEST_FREQ}}, BL-OPS-08).
5. Tracking & verification of the remediation in {{TOOL_TICKET}}.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Identification | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Assessment & prioritisation by criticality | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 3 | Initiate treatment | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Technical review | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | External service provider | - |
| 5 | Tracking & verification of the remediation | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Tracked vulnerabilities with treatment status in {{TOOL_TICKET}}; test reports. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Mean time to remediate per criticality
- Open critical vulnerabilities
- Scan coverage
## 9. Related documents
- Associated policy: {{LINK:R10}}
- {{LINK:VA-04}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-07_Kryptokonzept-und-Schluesselverwaltung.md
+69
View File
@@ -0,0 +1,69 @@
# Cryptography Concept and Key Management
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-07) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.1.1-M1, 5.1.1-M2, 5.1.1-S1, 5.1.2-M1, 5.1.2-S1, A.8.24-1 | POLICY R09 -->
## 1. Purpose
This procedure governs the use of cryptographic procedures and the management of keys throughout the lifecycle. It operationalises the associated policy ({{LINK:R09}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
New need for encryption/certificates; key renewal/revocation; change in the state of the art.
## 4. Inputs
- Permissible algorithms (BL-CRY-02)
- Protection need of the data
- Certificate/key inventory
## 5. Process
1. Determine need & procedure: select permissible algorithms {{CRYPTO_ALGO}} (BL-CRY-02).
2. Generate keys/certificates and distribute them securely (BL-CRY-05).
3. Storage & access protection (separate storage, {{#if FLAG_CRYPTO_PKI}}PKI, {{/if}}authorisations).
4. Ensure transmission protection: at least {{TLS_MIN}} (BL-CRY-01).
5. Document renewal/revocation/destruction.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Determine need & procedure | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 2 | Generate keys/certificates and distribute securely | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 3 | Storage & access protection (separate storage) | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Ensure transmission protection | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Document renewal/revocation/destruction | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Documented cryptography concept; traceable key/certificate lifecycle. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of compliant procedures/algorithms
- Expiring certificates without renewal
- Coverage of transport encryption
## 9. Related documents
- Associated policy: {{LINK:R09}}
- {{LINK:VA-04}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-08_Asset-und-Klassifizierungsverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Asset and Classification Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-08) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.3.1-M1, 1.3.1-M2, 1.3.1-S1, 1.3.2-M1, 1.3.2-M2, 1.3.2-S1, A.5.10-1, A.5.11-1, A.5.12-1, A.5.13-1, A.5.9-1, A.7.10-1, A.7.14-1, A.8.10-1 | POLICY R02 -->
## 1. Purpose
This procedure governs the recording, owner assignment, classification and maintenance of information assets and assets. It operationalises the associated policy ({{LINK:R02}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
New/changed asset; procurement; regular inventory review.
## 4. Inputs
- Procurement/change notification
- Classification scheme
- Asset inventory ({{TOOL_NAME}})
## 5. Process
1. Record the asset in the inventory ({{TOOL_NAME}}) with attributes.
2. Assign an owner.
3. Classify (confidentiality/integrity/availability) by the owner.
4. Apply handling requirements per protection class (labelling/storage/deletion BL-DEL-01).
5. Maintenance & review ({{REVIEW_CYCLE}}) for up-to-dateness.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Record the asset in the inventory ({{TOOL_NAME}}) | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Assign an owner | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | Asset owner |
| 3 | Classify (confidentiality/integrity) | Asset owner | Asset owner | {{ROLE_ISB}} | - |
| 4 | Apply handling requirements per protection class | Asset owner | {{ROLE_ISB}} | - | Employees |
| 5 | Maintenance & review ({{REVIEW_CYCLE}}) | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Up-to-date, classified asset inventory in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Inventory coverage
- Share of classified assets
- Assets without an owner
## 9. Related documents
- Associated policy: {{LINK:R02}}
- {{LINK:VA-03}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-09_Risikomanagement-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Risk Management Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-09) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.4.1-M1, 1.4.1-M2, 1.4.1-M3, 1.4.1-S1, 6.1.1-1, 6.1.2-1, 6.1.3-1, 8.2-1, 8.3-1 | POLICY R03 -->
## 1. Purpose
This procedure governs the identification, analysis, assessment, treatment and monitoring of information security risks. It operationalises the associated policy ({{LINK:R03}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
New system/project, incident, change, regular review cycle.
## 4. Inputs
- Asset/process list
- Assessment scales & acceptance thresholds
- Existing risk register
## 5. Process
1. Identify risks (assets, threats, vulnerabilities).
2. Analyse & assess (likelihood × impact) in the ISMS tool ({{TOOL_NAME}}).
3. Determine treatment (reduce/avoid/transfer/accept) and plan measures.
4. Document residual risk acceptance.
5. Monitor & update ({{REVIEW_CYCLE}} and on an ad-hoc basis).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Identify risks (assets, threats) | {{ROLE_ISB}} | {{ROLE_ISB}} | Asset/process owners | - |
| 2 | Analyse & assess (likelihood × impact) | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Determine treatment (reduce/avoid) | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | Business unit | - |
| 4 | Document residual risk acceptance | {{ROLE_MANAGEMENT}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 5 | Monitor & update ({{REVIEW_CYCLE}}) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Maintained risk register with treatment plan and acceptance decisions in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of treated risks
- Overdue measures
- Up-to-dateness of the risk register
## 9. Related documents
- Associated policy: {{LINK:R03}}
- {{LINK:VA-01}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-10_Lieferanten-Onboarding-und-Bewertung.md
+69
View File
@@ -0,0 +1,69 @@
# Supplier Onboarding and Assessment Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-10) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 6.1.1-M1, 6.1.1-M2, 6.1.1-S1, 6.1.2-M1, 6.1.2-S1, 6.1.3-M1, A.5.19-1, A.5.20-1, A.5.21-1, A.5.22-1 | POLICY R13 -->
## 1. Purpose
This procedure governs the selection, security-related assessment, contractual commitment and monitoring of suppliers/service providers. It operationalises the associated policy ({{LINK:R13}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
New supplier/service provider with access to information; contract renewal; periodic review.
## 4. Inputs
- Service/protection-need description
- Risk classes (BL-SUP-01)
- NDA/contract templates
## 5. Process
1. Determine need & risk class (protection need, access).
2. Carry out security assessment (self-disclosure/evidence/TISAX).
3. Agree NDA & contractual security requirements.
4. Delineate responsibilities (operations/security/reporting).
5. Add to the supplier register ({{TOOL_NAME}}) and review {{REVIEW_CYCLE}}.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Determine need & risk class (protection need, access) | Procurement/business unit | {{ROLE_ISB}} | - | - |
| 2 | Security assessment (self-disclosure/evidence/TISAX) | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | - |
| 3 | NDA & contractual security requirements | Procurement | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 4 | Delineate responsibilities (operations/security) | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 5 | Add to the supplier register ({{TOOL_NAME}}) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Assessed, contractually committed supplier in the supplier register ({{TOOL_NAME}}); NDA on file. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of assessed suppliers
- NDA coverage
- Overdue supplier reviews
## 9. Related documents
- Associated policy: {{LINK:R13}}
- {{LINK:VA-11}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-11_Cloud-und-KI-Freigabeverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Cloud and AI Approval Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-11) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.3.4-M1, 5.3.4-M2, 5.3.4-S1, 5.3.4-KI-M1, 5.3.4-KI-M2, 5.3.4-KI-M3, 5.3.4-KI-S1, A.5.23-1 | POLICY R12 -->
## 1. Purpose
This procedure governs the assessment and approval of cloud and AI/GenAI services as well as their permissible use. It operationalises the associated policy ({{LINK:R12}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Request to use a cloud or AI service.
## 4. Inputs
- Service description & provider information
- Protection need/data classes
- Contract/DPA documents
## 5. Process
1. Record the request in {{TOOL_TICKET}} (service, purpose, data classes).
2. Assessment: protection need, data location/EU, tenant separation, exit; for AI, exclusion of training/passing on.
3. Review contract/DPA (for AI: opt-out/enterprise contract, EU AI Act).
4. Approval & inclusion in the approval list ({{TOOL_NAME}}); define permissible data classes.
5. Use & control: human in the loop for AI, periodic review ({{REVIEW_CYCLE}}).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Record the request in {{TOOL_TICKET}} (service) | Requester/business unit | {{ROLE_ISB}} | - | - |
| 2 | Assessment | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | {{ROLE_DPO}} |
| 3 | Review contract/DPA (for AI) | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | {{ROLE_DPO}} | - |
| 4 | Approval & inclusion in the approval list | {{ROLE_ISB}} | {{ROLE_ISB}} | - | Business unit |
| 5 | Use & control | Business unit | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Approval decision and approval list in the ISMS tool ({{TOOL_NAME}}); documented permissible data classes. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of approved vs. used services
- Shadow IT findings
- Overdue service reviews
## 9. Related documents
- Associated policy: {{LINK:R12}}
- {{LINK:VA-10}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-12_Awareness-und-Schulungsverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Awareness and Training Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-12) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 2.1.3-M1, 2.1.3-S1, 7.3-1, A.6.3-1 | POLICY R05 -->
## 1. Purpose
This procedure governs the planning, delivery and evidence of awareness and training on information security. It operationalises the associated policy ({{LINK:R05}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Joining of new employees; annual training cycle; ad-hoc after incidents.
## 4. Inputs
- Training plan/curriculum (BL-HR-01)
- Target groups/roles
- Participation status ({{TOOL_NAME}})
## 5. Process
1. Plan training needs & target groups (role-specific).
2. Deliver onboarding training upon joining.
3. Deliver regular training ({{REVIEW_CYCLE}}, BL-HR-01).
4. Check effectiveness (phishing simulation) and provide follow-up training.
5. Evidence participation in the ISMS tool ({{TOOL_NAME}}).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Plan training needs & target groups (role-specific) | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | - |
| 2 | Deliver onboarding training upon joining | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - | Employees |
| 3 | Regular training ({{REVIEW_CYCLE}}, BL-HR-01) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | Employees |
| 4 | Check effectiveness (phishing simulation) | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 5 | Evidence participation in the ISMS tool ({{TOOL_NAME}}) | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Documented training participation and effectiveness measurement in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Training completion rate
- Phishing click rate
- Share of role-specific training
## 9. Related documents
- Associated policy: {{LINK:R05}}
- {{LINK:VA-01}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-13_Logging-und-Monitoring-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Logging and Monitoring Procedure
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-13) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.4-M1, 5.2.4-S1, A.8.15-1, A.8.16-1, A.8.17-1 | POLICY R10 -->
## 1. Purpose
This procedure governs the collection, protection, evaluation and retention of security-relevant log data. It operationalises the associated policy ({{LINK:R10}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Trigger
Continuous operations; security-relevant event; alert from {{TECH_SIEM}}.
## 4. Inputs
- Log sources/systems
- Retention requirements (BL-OPS-04)
- Alerting rules
## 5. Process
1. Connect log sources and record centrally in {{TECH_SIEM}} (BL-OPS-04).
2. Ensure tamper protection & retention {{LOG_RETENTION}}.
3. Evaluation & alerting: maintain rules, check anomalies.
4. Hand over suspected cases to incident response (VA-01).
5. Regular review of coverage and rules.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Connect log sources and record centrally in {{TECH_SIEM}} | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Tamper protection & retention {{LOG_RETENTION}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 3 | Evaluation & alerting | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Hand over suspected cases to incident response (VA-01) | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 5 | Regular review of coverage and rules | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Central, protected logging with evaluation; evidence in the ISMS tool ({{TOOL_NAME}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Log source coverage
- Mean time to alert response
- Share of evaluable events
## 9. Related documents
- Associated policy: {{LINK:R10}}
- {{LINK:VA-01}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-14_Personalsicherheit-Eignungspruefung.md
+71
View File
@@ -0,0 +1,71 @@
# Personnel Security – Suitability Check & Sensitive Activities
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-14) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_HR_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 2.1.1-M1, 2.1.1-M2, 2.1.1-M3, 2.1.1-S1, 2.1.1-S2, 2.1.2-M1, 2.1.2-M2, 2.1.2-S1, 2.1.2-S2, 2.1.2-S3, A.6.1-1, A.6.2-1, A.6.5-1, A.6.6-1 | POLICY R05 -->
## 1. Purpose
This procedure governs the determination of sensitive activities, the suitability and identity check upon hiring as well as the handling of violations of information security and confidentiality obligations. It operationalises the associated policy ({{LINK:R05}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all hiring, change and leaving processes.
## 3. Trigger
Hiring, change to a sensitive position, suspicion of a violation, regular review.
## 4. Inputs
- Register of sensitive activities ({{LINK:REG-SENS-ROLES}})
- Job descriptions with security requirements
- HR notification; legal framework (data protection/co-determination)
## 5. Process
1. Determine sensitive activity areas/roles in the **register of sensitive activities ({{LINK:REG-SENS-ROLES}})** and define the required depth of checking per role.
2. Record requirements for positions in job descriptions and ensure their fulfilment.
3. Upon hiring, verify identity; check personal suitability within the legally permissible scope (job interview).
4. For sensitive roles, carry out extended checks (references, criminal record certificate) within the legally permissible scope.
5. Handle violations of information security/confidentiality obligations following a documented procedure; evidence in the personnel file.
6. Review sensitive roles and depth of checking regularly ({{REVIEW_CYCLE}}).
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Determine sensitive activities & depth of checking | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | Business unit | - |
| 2 | Requirements in job descriptions | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | Business unit | - |
| 3 | Verify identity / check suitability | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Extended checks (sensitive roles) | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - |
| 5 | Handling of violations | {{ROLE_HR_LEAD}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 6 | Regular review | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | - |
## 7. Result & evidence
Maintained register of sensitive activities; documented suitability/verification evidence in the personnel file; documented violation cases. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of sensitive roles with documented depth of checking
- On-time identity/suitability checks
- Open violation cases
## 9. Related documents
- Associated policy: {{LINK:R05}}
- Register: {{LINK:REG-SENS-ROLES}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-15_Interne-Audits-und-Compliancepruefungen.md
+72
View File
@@ -0,0 +1,72 @@
# Internal Audits & Compliance Reviews
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-15) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.5.1-M1, 1.5.1-M2, 1.5.1-M3, 1.5.1-M4, 1.5.1-M5, 1.5.1-S1, 1.5.2-M1, 1.5.2-M2, 1.5.2-S1, 9.2-1, A.5.35-1, A.5.36-1, A.8.34-1 | POLICY R03 -->
## 1. Purpose
This procedure governs the programme, planning, execution, reporting and measure tracking of internal audits as well as the independent review of the ISMS. It operationalises the associated policy ({{LINK:R03}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all policies, procedures and technical requirements within the scope.
## 3. Trigger
Audit cycle (BL-GOV-01), material changes, request by management, prior findings.
## 4. Inputs
- Audit programme register ({{LINK:REG-AUDIT-PLAN}})
- Controls / statement of applicability (SoA)
- Previous audit reports & open measures
## 5. Process
1. Plan the **audit programme** in the **register ({{LINK:REG-AUDIT-PLAN}})** (scope, controls reviewed, dates, auditors) — cycle per **BL-GOV-01**.
2. Conduct the audit **independently** (auditor ≠ person responsible for the area reviewed).
3. Record findings/deviations and create them as measures in the ISMS tool ({{TOOL_NAME}}).
4. Report the audit report to {{ROLE_MANAGEMENT}} (input for the management review).
5. Track measures through to completion.
6. Independent review/assessment at least per **BL-GOV-01** or after fundamental changes.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Plan the audit programme | {{ROLE_ISB}} | {{ROLE_ISB}} | Business units | - |
| 2 | Conduct the audit | Auditor (independent) | {{ROLE_ISB}} | Area reviewed | - |
| 3 | Record findings / create measures | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | - |
| 4 | Report to management | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | - | {{ROLE_MANAGEMENT}} |
| 5 | Track measures | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | - |
| 6 | Independent review | External/independent auditor | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
## 7. Result & evidence
Audit reports, documented findings/measures and a maintained audit programme ({{LINK:REG-AUDIT-PLAN}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Audit coverage of the controls
- Open findings / on-time completion of measures
- Share of audits completed on time
## 9. Related documents
- Associated policy: {{LINK:R03}}
- Register: {{LINK:REG-AUDIT-PLAN}}
- Risk management procedure: {{LINK:VA-09}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-16_Sichere-Beschaffung-Entwicklung-und-Abnahme.md
+72
View File
@@ -0,0 +1,72 @@
# Secure Procurement, Development & Acceptance
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-16) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.3.1-M1, 5.3.1-M2, 5.3.1-M3, 5.3.1-M4, 5.3.1-S1, 5.3.1-S2, 5.3.1-S3, 5.3.1-S4, 5.3.1-S5, 5.3.1-V1, 5.3.2-M1, 5.3.2-S1, 5.3.2-S2, 5.3.2-S3, 5.3.2-H1, A.8.25-1, A.8.26-1, A.8.27-1, A.8.28-1, A.8.29-1, A.8.30-1, A.8.31-1, A.8.33-1, A.8.4-1 | POLICY R11 -->
## 1. Purpose
This procedure ensures that information security requirements are an integral part of the procurement, design, development, extension and modification of IT services and systems (security by design), including acceptance tests and test data handling. It operationalises the associated policy ({{LINK:R11}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for the procurement, in-house/external development and modification of IT services/systems.
## 3. Trigger
Procurement, new/further development or substantial modification of an IT service/system.
## 4. Inputs
- Security/protection-need requirements; applicable ISA controls
- Test/acceptance concept
- Where applicable, external services ({{LINK:REG-EXT-SERVICES}})
## 5. Process
1. Specify security requirements (security by design) and take the protection need into account.
2. Carry out procurement/modification based on the security criteria.{{#if FLAG_EXTERNAL_IT}} External/cloud services are assessed via {{LINK:VA-11}} and maintained in the {{LINK:REG-EXT-SERVICES}}.{{/if}}
3. Acceptance tests under security aspects before production deployment; approval in {{TOOL_TICKET}} (change coupling {{LINK:VA-04}}).
4. Avoid or anonymise production data in tests; protect test systems appropriately.
5. {{#if FLAG_DEV_INHOUSE}} For in-house development, secure coding requirements apply with code reviews and automated security tests (SAST/dependency scan).{{/if}}
6. {{#if FLAG_VERY_HIGH_PROTECTION}} Where the protection need is very high, an additional independent security review/acceptance is carried out before approval.{{/if}}
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Specify security requirements | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | Business unit | - |
| 2 | Carry out procurement/modification | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 3 | Security acceptance / approval | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | Business unit | - |
| 4 | Test data handling | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_DPO}} | - |
| 5 | Secure coding / security tests | Development | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 6 | Additional review (very high protection need) | Independent auditor | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
## 7. Result & evidence
Acceptance records, test reports and approvals (in {{TOOL_TICKET}}). Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of projects with a documented security acceptance
- Critical security findings before go-live
- Share of tests without real production data
## 9. Related documents
- Associated policy: {{LINK:R11}}
- Change procedure: {{LINK:VA-04}}
- Cloud/AI approval: {{LINK:VA-11}}; register: {{LINK:REG-EXT-SERVICES}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-17_Zutritts-und-Besuchermanagement.md
+67
View File
@@ -0,0 +1,67 @@
# Access & Visitor Management (physical)
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-17) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_IT_LEAD}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 3.1.1-S1, 3.1.1-S2, 3.1.1-S3, 3.1.1-S4, 3.1.1-S5, A.7.1-1, A.7.11-1, A.7.12-1, A.7.2-1, A.7.3-1, A.7.4-1, A.7.5-1, A.7.6-1, A.7.7-1, A.7.8-1 | POLICY R07 -->
## 1. Purpose
This procedure governs the granting and revocation of physical access rights, visitor management as well as the handling of utilities in security zones. It operationalises the associated policy ({{LINK:R07}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all sites and security zones.
## 3. Trigger
Joining/leaving/role change, visit, change to the zone concept, regular review.
## 4. Inputs
- Zone/security concept ({{LINK:BASELINE}}, BL-PHY-01/02)
- Personnel/visitor notification
- Existing access authorisations
## 5. Process
1. Access rights to security zones are requested, approved and revoked via {{TOOL_TICKET}} (least-privilege principle).
2. Visitors are registered, identified and escorted in areas requiring protection.
3. Utilities, keys and badges are issued, taken back and documented.
4. Access authorisations are reviewed regularly ({{REVIEW_CYCLE}}) and adjusted without delay upon leaving/change.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Grant/revoke access rights | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 2 | Register/escort visitors | Reception/business unit | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 3 | Manage utilities/keys | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 4 | Review access authorisations | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
## 7. Result & evidence
Up-to-date access authorisations and visitor logs. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Up-to-dateness of the access list
- Overdue recertifications of access rights
- Completeness of visitor logs
## 9. Related documents
- Associated policy: {{LINK:R07}}
- Authorisation procedure (logical analogue): {{LINK:VA-03}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-18_Datenschutz-und-Compliance-Pflege.md
+66
View File
@@ -0,0 +1,66 @@
# Data Protection & Compliance Maintenance
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-18) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_DPO}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 7.1.1-M1, 7.1.1-M2, 7.1.1-S1, 7.1.2-M1, 7.1.2-M2, 7.1.2-M3, A.5.31-1, A.5.32-1, A.5.33-1, A.5.34-1 | POLICY R14 -->
## 1. Purpose
This procedure governs the ongoing maintenance of the legal/compliance register, the record of processing activities (RoPA), deletion periods/deletion concept and the handling of data subject rights. It operationalises the associated policy ({{LINK:R14}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all processing of personal data as well as legal/contractual requirements.
## 3. Trigger
Regular review, new legal/contractual requirement, data subject request, new or changed processing.
## 4. Inputs
- Legal/compliance register (ISMS tool, {{TOOL_NAME}})
- Record of processing activities (RoPA)
- Deletion concept ({{LINK:BASELINE}}, BL-DEL-01)
## 5. Process
1. Review and update the legal/compliance register regularly ({{REVIEW_CYCLE}}).
2. Maintain the record of processing activities (RoPA) in the ISMS tool ({{TOOL_NAME}}).
3. Implement and monitor deletion periods and the deletion concept (BL-DEL-01).
4. Handle data subject rights on time; document the processing and the result.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Maintain legal/compliance register | {{ROLE_DPO}} | {{ROLE_ISB}} | Business unit | - |
| 2 | Maintain RoPA | {{ROLE_DPO}} | {{ROLE_DPO}} | Business unit | - |
| 3 | Implement/monitor deletion periods | {{ROLE_IT_LEAD}} | {{ROLE_DPO}} | {{ROLE_ISB}} | - |
| 4 | Handle data subject rights | {{ROLE_DPO}} | {{ROLE_DPO}} | {{ROLE_ISB}} | - |
## 7. Result & evidence
Up-to-date legal/compliance register and RoPA, deletion evidence, documented data subject requests. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Up-to-dateness of the legal/compliance register
- Data subject requests handled on time
- Overdue deletions
## 9. Related documents
- Associated policy: {{LINK:R14}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-19_Informationssicherheit-in-Projekten.md
+70
View File
@@ -0,0 +1,70 @@
# Information Security in Projects
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-19) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.2.3-M1, 1.2.3-S1, 1.2.3-S2, 1.2.3-S3, 1.2.3-H1, A.5.8-1 | POLICY R01 -->
## 1. Purpose
This procedure ensures that information security is taken into account in projects from the outset: project classification, risk assessment in an early phase and upon changes, derivation and tracking of measures as well as involvement of the ISO where the protection need is elevated. It operationalises the associated policy ({{LINK:R01}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all projects relating to information, IT systems or business processes.
## 3. Trigger
Project start, substantial project change, project completion.
## 4. Inputs
- Catalogue of criteria for project classification ({{LINK:BASELINE}}, BL-PROJ-01)
- Project register ({{LINK:REG-PROJECTS}})
- Risk assessment scale / risk register
## 5. Process
1. At the outset, classify the project with regard to its information security need on the basis of the **documented catalogue of criteria (BL-PROJ-01)**; entry in the **project register ({{LINK:REG-PROJECTS}})**.
2. Carry out a risk assessment in an early project phase and upon changes (coupling with risk management {{LINK:VA-09}}).
3. Derive measures and track them as tasks in {{TOOL_TICKET}}.
4. {{#if FLAG_ELEVATED_PROTECTION}} Where the protection need is elevated, {{ROLE_ISB}} is involved; additional reviews/approvals take place before critical milestones.{{/if}}
5. Before project completion, review the implementation of the measures and document it in the project register.
## 6. RACI
| # | Step | R (Execution) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Classify the project | Project management | {{ROLE_ISB}} | {{ROLE_ISB}} | - |
| 2 | Carry out risk assessment | Project management | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Derive & track measures | Project management | Project management | {{ROLE_ISB}} | - |
| 4 | ISO involvement (elevated protection need) | {{ROLE_ISB}} | {{ROLE_ISB}} | Project management | {{ROLE_MANAGEMENT}} |
| 5 | Final review of measures | Project management | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Maintained project register with classification, risk assessment and measure status. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of classified projects
- Open project security measures
- Share of projects with ISO involvement where the protection need is elevated
## 9. Related documents
- Associated policy: {{LINK:R01}}
- Register: {{LINK:REG-PROJECTS}}
- Risk management procedure: {{LINK:VA-09}}
- Technical security baseline: {{LINK:BASELINE}}
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-20_Prototypen-Zutritt-und-Transport.md
+38
View File
@@ -0,0 +1,38 @@
# Prototype Access and Transport
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-20) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 8.1.1-M1, 8.3.1-M1 | POLICY P01 -->
## 1. Purpose
This procedure operationalises the Prototype Protection policy ({{LINK:P01}}). It governs access to prototype areas as well as the transport and storage of prototypes so that confidentiality and integrity are ensured.
## 2. Scope
The procedure applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) for all persons and areas involved with prototypes.
## 3. Process
### 3.1 Access
- Access to prototype areas only for individually authorised persons; visitors are escorted and logged.
- Access rights are reviewed regularly and revoked where necessary.
### 3.2 Transport and storage
- Transport in secured, sealed containers with logged handover.
- Storage in secured zones with access and visual protection; check-in and check-out are documented in a traceable manner.
## 4. Evidence
Access, handover and storage logs are maintained in accordance with the evidence register ({{LINK:NACHWEISREGISTER}}).
seed/isms-vorlagenpaket-v2-en/verfahren/VA-21_Nichtkonformitaeten-und-Korrekturmassnahmen.md
+78
View File
@@ -0,0 +1,78 @@
# Nonconformities & Corrective Actions
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-21) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 10.1-1, 10.2-1 | POLICY R03 -->
## 1. Purpose
This procedure governs the recording, root cause analysis, treatment and effectiveness review of nonconformities and the continual improvement of the ISMS derived from them. It elaborates the corresponding policy ({{LINK:R03}}).
> The procedure also carries the requirement to correct and follow up deviations, as required by the compliance review in security operations ({{LINK:VA-15}}) — it therefore applies regardless of which framework the organisation follows.
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) to all nonconformities against policies, procedures, technical requirements as well as legal and contractual obligations.
## 3. Trigger
Audit finding, result of a compliance review, security incident, deviation of a metric from its target value, report from operations or third parties, observation during the management review.
## 4. Inputs
- Audit reports and findings ({{LINK:VA-15}})
- Incidents and lessons learned ({{LINK:VA-01}})
- Metrics deviating from their target value ({{LINK:VA-22}})
- Risk register and risk treatment plan ({{LINK:VA-09}})
## 5. Process
1. **Record:** create the nonconformity in the ISMS tool ({{TOOL_NAME}}) with origin, description and affected area.
2. **Respond immediately:** decide the correction to control the deviation and how to deal with its consequences.
3. **Analyse the cause:** determine the cause and evaluate whether similar nonconformities exist or could occur elsewhere.
4. **Define corrective action:** decide the action with a responsible role and a due date; size it to the cause, not to the symptom.
5. **Implement and follow up:** track implementation in {{TOOL_NAME}}; delay escalates to {{ROLE_ISB}}.
6. **Review effectiveness:** after the defined effectiveness interval, verify that the cause has been eliminated; adjust risks, controls and documents where necessary.
7. **Close:** document and retain the nature of the nonconformity, the actions taken and the result of the effectiveness review.
## 6. RACI
| # | Step | R (execution) | A (accountable) | C (consulted) | I (informed) |
|---|------|---------------|-----------------|---------------|--------------|
| 1 | Record | Reporting person / auditor | {{ROLE_ISB}} | - | - |
| 2 | Respond immediately | Business unit | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Analyse the cause | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | - |
| 4 | Define corrective action | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | Business unit | - |
| 5 | Implement and follow up | Action owner | {{ROLE_ISB}} | - | {{ROLE_MANAGEMENT}} |
| 6 | Review effectiveness | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | {{ROLE_MANAGEMENT}} |
| 7 | Close | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |
## 7. Result & evidence
Action register with root cause analysis, due dates and documented effectiveness review in {{TOOL_NAME}}. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Number of open nonconformities by age
- On-time completion of corrective actions
- Share of actions with confirmed effectiveness
- Recurrence rate of similar nonconformities
## 9. Related documents
- Corresponding policy: {{LINK:R03}}
- Internal audits: {{LINK:VA-15}}
- Management review and metrics: {{LINK:VA-22}}
- Incident response: {{LINK:VA-01}}
- Technical security baseline: {{LINK:BASELINE}}
<!-- Fulfils the requirements listed under FULFILLS above; coupling in mapping-iso.json. Not visible in reading mode. -->
seed/isms-vorlagenpaket-v2-en/verfahren/VA-22_Managementbewertung-und-Kennzahlen.md
+77
View File
@@ -0,0 +1,77 @@
# Management Review & Metrics
| Document information | Value |
|-----------------------|------|
| Document type | Procedure instruction (VA-22) |
| Scope | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Process owner | {{ROLE_ISB}} |
| Approved by | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Date | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 9.1-1, 9.3-1 | POLICY R03 -->
## 1. Purpose
This procedure governs how information security performance is measured and evaluated and how top management reviews the ISMS at planned intervals. It elaborates the corresponding policy ({{LINK:R03}}).
## 2. Scope
Applies within the ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}) to all information security metrics and to the management review of the ISMS.
## 3. Trigger
Measurement interval of the respective metric, date of the management review (BL-GOV-02), significant changes within the scope, severe incident.
## 4. Inputs
- Metrics sheet with target values and owners ({{TOOL_NAME}})
- Audit results and open findings ({{LINK:VA-15}})
- Nonconformities and corrective actions ({{LINK:VA-21}})
- Risk assessment and status of the risk treatment plan ({{LINK:VA-09}})
- Incidents and reporting obligations ({{LINK:VA-01}})
- Feedback from interested parties
## 5. Process
1. **Define metrics:** for each metric determine what is measured, by which method and data source, at which interval, who measures, when it is analysed and who analyses it.
2. **Measure:** collect the values at the defined interval and record them in {{TOOL_NAME}}.
3. **Analyse:** evaluate the results against the target values and form trends; a deviation from the target value raises a nonconformity ({{LINK:VA-21}}).
4. **Prepare the management review:** compile the inputs — status of actions from previous reviews, changes in relevant internal and external issues and in the requirements of interested parties, feedback on information security performance, feedback from interested parties, results of the risk assessment, opportunities for improvement.
5. **Conduct the review:** {{ROLE_MANAGEMENT}} reviews the ISMS at the interval {{MGMT_REVIEW_CYCLE}} against the fixed agenda (BL-GOV-02).
6. **Take decisions:** decisions on opportunities for improvement and on any need to change the ISMS, each with a responsible role and a due date.
7. **Record and follow up:** retain the minutes in {{TOOL_NAME}}; track the decisions through to completion.
## 6. RACI
| # | Step | R (execution) | A (accountable) | C (consulted) | I (informed) |
|---|------|---------------|-----------------|---------------|--------------|
| 1 | Define metrics | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | {{ROLE_IT_LEAD}} | Business units |
| 2 | Measure | Metric owner | {{ROLE_ISB}} | - | - |
| 3 | Analyse | {{ROLE_ISB}} | {{ROLE_ISB}} | Business unit | - |
| 4 | Prepare the review | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 5 | Conduct the review | {{ROLE_MANAGEMENT}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | Business units |
| 6 | Take decisions | {{ROLE_MANAGEMENT}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 7 | Record and follow up | {{ROLE_ISB}} | {{ROLE_ISB}} | - | {{ROLE_MANAGEMENT}} |
## 7. Result & evidence
A maintained metrics sheet with measured values per period and minutes of the management review with decisions, owners and due dates. Evidence is referenced in the central evidence register ({{LINK:NACHWEISREGISTER}}).
## 8. Key performance indicators (KPI)
- Share of metrics actually collected at the defined interval
- Share of metrics within their target value
- On-time completion of decisions from the management review
## 9. Related documents
- Corresponding policy: {{LINK:R03}}
- Nonconformities and corrective actions: {{LINK:VA-21}}
- Internal audits: {{LINK:VA-15}}
- Risk management procedure: {{LINK:VA-09}}
- Technical security baseline: {{LINK:BASELINE}}
<!-- Fulfils the requirements listed under FULFILLS above; coupling in mapping-iso.json. Not visible in reading mode. -->
seed/isms-vorlagenpaket-v2/00_Integrationsleitfaden_Wizard.md
+148
View File
@@ -0,0 +1,148 @@
# Integrationsleitfaden für den Programmierer – ISMS-Vorlagenpaket v2
Dieses Dokument beschreibt, wie die Richtlinien-Templates, Variablen, das versteckte Anforderungs-Mapping und die Verlinkungen in den Wizard/das Tool eingebaut werden. Zielgruppe: die Person, die den Wizard implementiert.
## 1. Paketstruktur
```
ISMS-Vorlagenpaket-v2/
├── 00_Integrationsleitfaden_Wizard.md ← dieses Dokument
├── variables.schema.json ← alle Wizard-Variablen (Single Source of Truth)
├── mapping.json ← Anforderungs-Mapping (REQ/IMPL ↔ ISA-Control ↔ Richtlinie)
├── ISA-Mapping-Matrix.md ← menschenlesbare ISA-Matrix (ersetzt "Bezug zu VDA ISA")
├── Technische-Sicherheits-Baseline.md ← zentrale konkrete Parameter (BL-IDs), einzige Pflegestelle
├── Nachweisregister_zentral.md ← zentrales Nachweis-Template
├── richtlinien/
│ ├── L00_Informationssicherheitsleitlinie.md
│ └── R01 … R14
└── verfahren/
└── VA-01 … VA-13 ← Verfahrensanweisungen (Abläufe zu den Richtlinien)
```
**Richtlinie vs. Verfahren:** Die Richtlinie (R01–R14) sagt *was* gilt und *wie* es grundsätzlich umgesetzt ist. Die Verfahrensanweisung (VA-01–VA-13) beschreibt den konkreten *Ablauf* (Auslöser → Schritte → RACI → Ergebnis/Nachweis). Jedes Verfahren trägt einen Hidden-Anker `<!-- FULFILLS <req-ids> | POLICY <Rxx> -->`; die erfüllten Anforderungen sind zusätzlich je Eintrag in `mapping.json` (`verfahren`-Liste) und je Anforderung (`verfahren`-Feld) hinterlegt. So fließen Verfahren automatisch in die Nachweisdokumentation ein.
## 2. Vier Bausteine im Überblick
1. **Variablen** (`{{NAME}}`, UPPER_SNAKE) – organisationsspezifische Werte, aus `variables.schema.json`.
2. **Bedingungsblöcke** (`{{#if FLAG_X}} … {{/if}}`) – blenden Anforderungen/Abschnitte je nach Feature-Flag und Reifegrad ein/aus.
3. **Hidden-Anker** (`<!-- REQ … -->` / `<!-- IMPL … -->`) – unsichtbare IDs je Einzelanforderung; Grundlage für Nachweis-Mapping und Deep-Links.
4. **Link-Platzhalter** (`{{LINK:ZIEL}}`) – Verweise zwischen Dokumenten und zu Nachweisen, die das Tool zur Laufzeit auflöst.
## 3. Templating-Konvention (Handlebars-kompatibel)
| Konstrukt | Bedeutung |
|-----------|-----------|
| `{{ORG_NAME}}` | Variablen-Einsetzung |
| `{{#if FLAG_CLOUD_USED}} … {{/if}}` | bedingter Block (Feature-Flag) |
| `{{#if FLAG_INCLUDE_SHOULD}} … {{/if}}` | SOLL-Anforderungen ein-/ausblenden (Reifegrad) |
| `[MUSS]` / `[SOLL]` | Text-Kennzeichnung der Anforderungsstufe |
| `<!-- REQ 1.2.1-M1 -->` | Hidden-Anker vor einer Anforderung |
| `<!-- IMPL 1.2.1-M1 -->` | Hidden-Anker vor dem zugehörigen Umsetzungstext |
| `{{LINK:R02}}` | Link-Platzhalter (siehe Abschnitt 6) |
Beim Rendern: Variablen einsetzen, `{{#if}}`-Blöcke nach Kontext auflösen, `{{LINK:…}}` in echte Links übersetzen. Die `<!-- … -->`-Anker **im Dokument belassen** (sie sind im Lesemodus unsichtbar) – das Tool braucht sie zur Laufzeit für Deep-Links und Nachweiszuordnung. Für den PDF-/Druckexport können sie entfernt werden.
## 4. Aufbau einer thematischen Richtlinie (R01–R14)
```
### 3.1 <Control-Titel> (ISA 1.2.1)
**Anforderung**
<!-- REQ 1.2.1-M1 -->
- **[MUSS]** <normativer Anforderungstext>
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.1-S1 -->
- **[SOLL]** <SOLL-Anforderung>
{{/if}}
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.2.1-M1 -->
<vorformulierter Ist-Text mit Variablen/Optionalblöcken>
```
Jede Anforderung (`REQ`) hat genau eine Umsetzung (`IMPL`) mit identischer ID. Ausnahme **L00** (Leitlinie): kombiniertes Dokument, dort ist `IMPL`-Anker = `REQ`-Anker (in `mapping.json` bereits so hinterlegt).
**ID-Schema:** `<ISA-Control>-<M|S><laufnr>`, z. B. `1.2.1-M1`, `5.2.9-S1`. MUSS und SOLL werden getrennt nummeriert.
## 5. `mapping.json` – das versteckte Anforderungs-Mapping
Zentrale Datei, die je Einzelanforderung Metadaten bündelt. Aufbau je Eintrag:
```json
{
"id": "1.2.1-M1",
"policy": "R01",
"policy_file": "R01_ISMS-Organisation-und-Rollen.md",
"control": "1.2.1",
"type": "MUSS",
"req_anchor": "REQ 1.2.1-M1",
"impl_anchor": "IMPL 1.2.1-M1",
"condition": null,
"requirement": "Der Geltungsbereich des ISMS … ist bestimmt und dokumentiert.",
"implementation": "Der ISMS-Geltungsbereich ist im ISMS-Tool … dokumentiert.",
"link": "{{LINK:R01#1.2.1}}",
"nachweis_link": "{{LINK:NACHWEISREGISTER}}"
}
```
- `condition` = `null` (immer aktiv), `"FLAG_INCLUDE_SHOULD"` (nur bei SOLL) oder ein Feature-Flag. Anforderungen, deren Bedingung im Kontext `false` ist, erscheinen im Dokument nicht und werden in der Nachweisdoku übersprungen.
- **Reading-Mode:** Der Anwender sieht nur Anforderung + Umsetzung, keine IDs. Das Tool blendet je Anforderung eine dezente Verlinkung („Nachweise") ein, die über `nachweis_link` bzw. die ID auf den Nachweiseintrag zeigt.
## 6. Link-Platzhalter `{{LINK:ZIEL}}` auflösen
Das Tool ersetzt Platzhalter durch echte Deep-Links (unabhängig von Dateipfaden):
| Platzhalter | Ziel |
|-------------|------|
| `{{LINK:L00}}` … `{{LINK:R14}}` | jeweiliges Richtlinien-Dokument |
| `{{LINK:R01#1.2.1}}` | Sprungziel auf Control-Abschnitt (Anker aus ID ableitbar) |
| `{{LINK:NACHWEISREGISTER}}` | zentrales Nachweisregister |
| `{{LINK:ISA_MAPPING}}` | ISA-Mapping-Matrix |
| `{{LINK:BASELINE}}` | Technische Sicherheits-Baseline |
| `{{LINK:VA-01}}` … `{{LINK:VA-13}}` | Verfahrensanweisungen |
**Konkrete Parameter (Passwort, Fristen, Krypto …):** liegen ausschließlich in `Technische-Sicherheits-Baseline.md` und im Schema (Variablen wie `PW_MIN_LENGTH`, `LOG_RETENTION`). Die Umsetzungstexte referenzieren die Baseline-IDs (`BL-IAM-01` …) und rendern die Werte über dieselben Variablen – so gibt es genau eine Pflegestelle je Wert.
Empfehlung: eine Auflösungstabelle `DOC_ID → interne Tool-URL` pflegen; unbekannte Ziele als Warnung loggen.
## 7. Wizard-Ablauf (empfohlen)
1. **Schema laden** (`variables.schema.json`) → Eingabemasken erzeugen. Reihenfolge: Organisation → Geltungsbereich → Rollen → ISMS-Tool → Feature-Flags → Reifegrad → tech. Lösungen (TECH_*) → Metadaten.
2. **Kontext validieren** (Pflichtfelder `required`, Defaults übernehmen).
3. **Rendern** je Dokument: Variablen einsetzen, `{{#if}}` auflösen, `{{LINK}}` übersetzen, Hidden-Anker belassen.
4. **Mapping filtern**: aus `mapping.json` alle Anforderungen entfernen, deren `condition` im Kontext `false` ist → ergibt die **aktive Anforderungsliste** dieses Mandanten.
5. **Speichern/Verknüpfen** im Tool.
### Minimal-Render (Node/Handlebars)
```js
import Handlebars from "handlebars";
const render = (tpl, ctx) =>
Handlebars.compile(tpl, { noEscape: true })(ctx) // Hidden-Anker bleiben erhalten
.replace(/\{\{LINK:([^}]+)\}\}/g, (_, id) => resolveLink(id));
```
## 8. Nachweisdokumentation aus dem Mapping bauen
Genau der Zweck des Mappings: Aus `mapping.json` + Nachweiseinträgen lässt sich per Knopfdruck eine Nachweisdoku erzeugen. Vorgehen:
1. Aktive Anforderungen ermitteln (Abschnitt 7, Schritt 4).
2. Je Anforderung: `id`, `type`, `requirement`, `implementation`, Link zur Richtlinie (`link`) und zum Nachweis (`nachweis_link`) zusammenstellen.
3. Nachweise aus {{TOOL_NAME}} anhängen (Owner/Turnus aus `Nachweisregister_zentral.md`).
4. Ausgabe als Tabelle/Export (z. B. für das VDA-ISA-Assessment: Spalten „Implementation description" = `implementation`, „Reference documentation" = Nachweis-Link).
So entsteht die Assessment-Sicht, ohne dass der Anwender im Lesemodus mit IDs konfrontiert wird.
## 9. Cross-Links zwischen Dokumenten
Jede Richtlinie enthält einen Abschnitt **„Verwandte Dokumente"** mit `{{LINK:…}}` auf Leitlinie, ISA-Matrix, Nachweisregister und thematisch verwandte Richtlinien. Innerhalb der Umsetzungstexte stehen zusätzlich kontextbezogene Verweise (z. B. R08 verweist bei Zugriffsrechten auf R10). Das Tool löst alle Platzhalter einheitlich auf.
## 10. Pflege & Konsistenz
- **Neue Variable:** zuerst in `variables.schema.json`, dann im Template verwenden.
- **Neue Anforderung/Control:** Anforderung + Umsetzung im Template ergänzen (mit `REQ`/`IMPL`-Ankern) **und** Eintrag in `mapping.json`; ISA-Matrix neu erzeugen.
- **Konsistenzcheck vor Auslieferung (empfohlen):** (a) jeder `{{NAME}}` existiert im Schema; (b) jeder `REQ`/`IMPL`-Anker im Dokument hat einen `mapping.json`-Eintrag und umgekehrt; (c) jedes `{{LINK:…}}`-Ziel ist auflösbar. Die mitgelieferten Generatoren (`_generate_v2.py`, `_matrix.py`) sind die Referenzimplementierung dieser Regeln.
## 11. Reifegrad
`FLAG_INCLUDE_SHOULD = true` → Reifegrad 3 (MUSS + SOLL). `false` → reines MUSS-Set. Höhere Reifegrade (4/5) lassen sich später als zusätzliche `condition`-Stufe (z. B. `FLAG_LEVEL_4`) ergänzen, ohne die Struktur zu ändern.
seed/isms-vorlagenpaket-v2/ISA-Mapping-Matrix.md
+379
View File
@@ -0,0 +1,379 @@
# ISA-Mapping-Matrix - VDA ISA 2027 (Information Security)
Zentrale Zuordnung **ISA-Control -> Richtlinie -> Einzelanforderungen** über alle Schutzbedarf-Ebenen (MUSS/SOLL/HOCH/SEHR HOCH). Anforderungen 1:1 aus der ISA übernommen; Kopplung über `mapping.json` und Hidden-Anker. Verweise: {{LINK:NACHWEISREGISTER}}, {{LINK:BASELINE}}.
| ISA | Richtlinie | MUSS | SOLL | HOCH | SEHR HOCH | Verfahren |
|-----|-----------|------|------|------|-----------|-----------|
| 1.1.1 | {{LINK:L00}} Informationssicherheitsleitlinie | 5 | 4 | 0 | 0 | - |
| 1.2.1 | {{LINK:R01}} ISMS-Organisation und Rollen | 6 | 0 | 0 | 0 | - |
| 1.2.2 | {{LINK:R01}} ISMS-Organisation und Rollen | 4 | 2 | 1 | 0 | - |
| 1.2.3 | {{LINK:R01}} ISMS-Organisation und Rollen | 1 | 3 | 1 | 0 | - |
| 1.3.1 | {{LINK:R02}} Asset- und Klassifizierung | 2 | 1 | 0 | 0 | VA-08 |
| 1.3.2 | {{LINK:R02}} Asset- und Klassifizierung | 3 | 1 | 0 | 0 | VA-08 |
| 1.3.3 | {{LINK:R02}} Asset- und Klassifizierung | 2 | 4 | 0 | 0 | - |
| 1.3.4 | {{LINK:R02}} Asset- und Klassifizierung | 2 | 5 | 0 | 1 | - |
| 1.4.1 | {{LINK:R03}} Risikomanagement und Audit | 4 | 4 | 0 | 0 | VA-09 |
| 1.5.1 | {{LINK:R03}} Risikomanagement und Audit | 5 | 1 | 0 | 0 | - |
| 1.5.2 | {{LINK:R03}} Risikomanagement und Audit | 2 | 1 | 0 | 0 | - |
| 1.6.1 | {{LINK:R04}} Incident, Notfall und Kontinuität | 3 | 6 | 0 | 1 | VA-01 |
| 1.6.2 | {{LINK:R04}} Incident, Notfall und Kontinuität | 3 | 3 | 5 | 1 | VA-01 |
| 1.6.3 | {{LINK:R04}} Incident, Notfall und Kontinuität | 3 | 6 | 5 | 1 | VA-02 |
| 2.1.1 | {{LINK:R05}} Personalsicherheit und Awareness | 3 | 2 | 0 | 0 | - |
| 2.1.2 | {{LINK:R05}} Personalsicherheit und Awareness | 2 | 3 | 0 | 0 | - |
| 2.1.3 | {{LINK:R05}} Personalsicherheit und Awareness | 1 | 6 | 0 | 0 | VA-12 |
| 2.1.4 | {{LINK:R06}} Mobiles Arbeiten und mobile Geräte | 1 | 2 | 1 | 0 | - |
| 3.1.1 | {{LINK:R07}} Physische Sicherheit | 3 | 5 | 1 | 0 | - |
| 3.1.4 | {{LINK:R06}} Mobiles Arbeiten und mobile Geräte | 1 | 1 | 1 | 0 | - |
| 4.1.1 | {{LINK:R08}} Identitäts- und Zugriffsmanagement | 1 | 1 | 1 | 0 | VA-03 |
| 4.1.2 | {{LINK:R08}} Identitäts- und Zugriffsmanagement | 2 | 3 | 1 | 1 | - |
| 4.1.3 | {{LINK:R08}} Identitäts- und Zugriffsmanagement | 7 | 10 | 0 | 0 | VA-03 |
| 4.2.1 | {{LINK:R08}} Identitäts- und Zugriffsmanagement | 2 | 5 | 1 | 2 | VA-03 |
| 5.1.1 | {{LINK:R09}} Kryptografie und Übertragung | 1 | 1 | 1 | 0 | VA-07 |
| 5.1.2 | {{LINK:R09}} Kryptografie und Übertragung | 3 | 3 | 1 | 1 | VA-07 |
| 5.2.1 | {{LINK:R10}} Betriebssicherheit | 1 | 4 | 1 | 0 | VA-04 |
| 5.2.2 | {{LINK:R10}} Betriebssicherheit | 2 | 1 | 0 | 0 | - |
| 5.2.3 | {{LINK:R10}} Betriebssicherheit | 2 | 8 | 0 | 0 | - |
| 5.2.4 | {{LINK:R10}} Betriebssicherheit | 5 | 3 | 2 | 1 | VA-13 |
| 5.2.5 | {{LINK:R10}} Betriebssicherheit | 3 | 3 | 0 | 0 | VA-04, VA-06 |
| 5.2.6 | {{LINK:R10}} Betriebssicherheit | 5 | 3 | 1 | 1 | VA-06 |
| 5.2.7 | {{LINK:R10}} Betriebssicherheit | 2 | 2 | 1 | 0 | - |
| 5.2.8 | {{LINK:R04}} Incident, Notfall und Kontinuität | 2 | 3 | 7 | 3 | VA-02 |
| 5.2.9 | {{LINK:R10}} Betriebssicherheit | 2 | 1 | 2 | 3 | VA-05 |
| 5.3.1 | {{LINK:R11}} Sichere Beschaffung und Entwicklung | 4 | 5 | 0 | 1 | - |
| 5.3.2 | {{LINK:R11}} Sichere Beschaffung und Entwicklung | 1 | 3 | 1 | 0 | - |
| 5.3.3 | {{LINK:R11}} Sichere Beschaffung und Entwicklung | 0 | 1 | 0 | 0 | - |
| 5.3.4 | {{LINK:R12}} Cloud-, KI- und externe IT-Dienste | 1 | 1 | 0 | 0 | VA-11 |
| 5.3.4-KI | {{LINK:R12}} Cloud-, KI- und externe IT-Dienste | 3 | 1 | 0 | 0 | VA-11 |
| 6.1.1 | {{LINK:R13}} Lieferanten- und Dienstleistersteuerung | 3 | 2 | 3 | 2 | VA-10 |
| 6.1.2 | {{LINK:R13}} Lieferanten- und Dienstleistersteuerung | 4 | 5 | 0 | 0 | VA-10 |
| 6.1.3 | {{LINK:R13}} Lieferanten- und Dienstleistersteuerung | 5 | 2 | 5 | 0 | VA-10 |
| 7.1.1 | {{LINK:R14}} Compliance und Datenschutz | 2 | 1 | 0 | 0 | - |
| 7.1.2 | {{LINK:R14}} Compliance und Datenschutz | 3 | 0 | 0 | 0 | - |
**Summe:** 316 Anforderungen (MUSS 122, SOLL 132, HOCH 43, SEHR HOCH 19) — davon 312 1:1 aus VDA ISA und 4 kundenspezifische Ergänzung (KI). Controls: 45.
> 3.1.2 in ISA 2027 als 'Superseded by 1.6.3, 5.2.8 und 5.2.9' entfallen - abgedeckt über {{LINK:R04}} und {{LINK:R10}}.
## Detailzuordnung je Anforderung
| ID | Ebene | Richtlinie | Anforderung (Kurz) | Bedingung |
|----|-------|-----------|--------------------|-----------|
| 1.1.1-M1 | MUSS | L00 | Die Anforderungen der Informationssicherheit sind bestimmt, dokumentiert und an den Zielen... | - |
| 1.1.1-M2 | MUSS | L00 | Eine Leitlinie existiert und ist durch die Leitung der Organisation genehmigt. | - |
| 1.1.1-M3 | MUSS | L00 | Die Leitlinie benennt Ziele und die Bedeutung der Informationssicherheit innerhalb der Org... | - |
| 1.1.1-M4 | MUSS | L00 | Die Leitlinien werden den Beschäftigten in geeigneter Form zur Verfügung gestellt (z. B. I... | - |
| 1.1.1-M5 | MUSS | L00 | Beschäftigte und externe Geschäftspartner werden über für sie relevante Änderungen informi... | - |
| 1.1.1-S1 | SOLL | L00 | Die Informationssicherheitsanforderungen basieren auf der Strategie der Organisation; Gese... | FLAG_INCLUDE_SHOULD |
| 1.1.1-S2 | SOLL | L00 | Die Leitlinie benennt Konsequenzen bei Nichteinhaltung. | FLAG_INCLUDE_SHOULD |
| 1.1.1-S3 | SOLL | L00 | Weitere relevante Sicherheitsrichtlinien sind etabliert. | FLAG_INCLUDE_SHOULD |
| 1.1.1-S4 | SOLL | L00 | Regelmäßige Überprüfung und ggf. Überarbeitung der Richtlinien sind etabliert. | FLAG_INCLUDE_SHOULD |
| 1.2.1-M1 | MUSS | R01 | Der Geltungsbereich des ISMS (die durch das ISMS gesteuerte Organisation) ist definiert. | - |
| 1.2.1-M2 | MUSS | R01 | Die Anforderungen der Organisation an das ISMS sind bestimmt. | - |
| 1.2.1-M3 | MUSS | R01 | Die Organisationsleitung hat das ISMS beauftragt und genehmigt. | - |
| 1.2.1-M4 | MUSS | R01 | Das ISMS stellt der Organisationsleitung geeignete Mittel zur Überwachung und Steuerung be... | - |
| 1.2.1-M5 | MUSS | R01 | Die anwendbaren Controls sind bestimmt (z. B. ISO-27001-Anwendbarkeitserklärung oder ausge... | - |
| 1.2.1-M6 | MUSS | R01 | Die Wirksamkeit des ISMS wird regelmäßig durch die Leitung überprüft. | - |
| 1.2.2-M1 | MUSS | R01 | Verantwortlichkeiten für Informationssicherheit sind definiert, dokumentiert und zugewiese... | - |
| 1.2.2-M2 | MUSS | R01 | Die verantwortlichen Beschäftigten sind definiert, qualifiziert und für ihre Aufgabe befäh... | - |
| 1.2.2-M3 | MUSS | R01 | Die erforderlichen Ressourcen stehen zur Verfügung. | - |
| 1.2.2-M4 | MUSS | R01 | Die Ansprechpartner sind innerhalb der Organisation und relevanten Geschäftspartnern bekan... | - |
| 1.2.2-S1 | SOLL | R01 | Es besteht eine Definition und Dokumentation einer angemessenen Informationssicherheitsstr... | FLAG_INCLUDE_SHOULD |
| 1.2.2-S2 | SOLL | R01 | Sicherheitsrelevante Rollen, die nicht Teil des ISMS, aber für die Informationssicherheit ... | FLAG_INCLUDE_SHOULD |
| 1.2.2-H1 | HOCH | R01 | Eine angemessene organisatorische Trennung von Verantwortlichkeiten ist etabliert, um Inte... | FLAG_HIGH_PROTECTION |
| 1.2.3-M1 | MUSS | R01 | Projekte werden unter Berücksichtigung der Informationssicherheitsanforderungen klassifizi... | - |
| 1.2.3-S1 | SOLL | R01 | Verfahren und Kriterien für die Klassifizierung von Projekten sind dokumentiert. | FLAG_INCLUDE_SHOULD |
| 1.2.3-S2 | SOLL | R01 | In einer frühen Projektphase wird eine Risikobewertung nach dem definierten Verfahren durc... | FLAG_INCLUDE_SHOULD |
| 1.2.3-S3 | SOLL | R01 | Für identifizierte Informationssicherheitsrisiken werden Maßnahmen abgeleitet und im Proje... | FLAG_INCLUDE_SHOULD |
| 1.2.3-H1 | HOCH | R01 | Die abgeleiteten Maßnahmen werden während des Projekts regelmäßig überprüft und bei Änderu... | FLAG_HIGH_PROTECTION |
| 1.3.1-M1 | MUSS | R02 | Informationswerte und weitere sicherheitsrelevante Assets der Organisation sind identifizi... | - |
| 1.3.1-M2 | MUSS | R02 | Die unterstützenden Assets, die die Informationswerte verarbeiten, sind identifiziert und ... | - |
| 1.3.1-S1 | SOLL | R02 | Ein Katalog der relevanten Informationswerte existiert; dabei werden die einschlägigen Asp... | FLAG_INCLUDE_SHOULD |
| 1.3.2-M1 | MUSS | R02 | Ein konsistentes Schema zur Klassifizierung von Informationswerten hinsichtlich des Schutz... | - |
| 1.3.2-M2 | MUSS | R02 | Die Bewertung der identifizierten Informationswerte erfolgt nach den definierten Kriterien... | - |
| 1.3.2-M3 | MUSS | R02 | Vorgaben zur Handhabung unterstützender Assets (z. B. Kennzeichnung, Nutzung, Transport, S... | - |
| 1.3.2-S1 | SOLL | R02 | Die Schutzziele Integrität und Verfügbarkeit werden berücksichtigt. | FLAG_INCLUDE_SHOULD |
| 1.3.3-M1 | MUSS | R02 | Externe IT-Dienste werden nicht ohne ausdrückliche Bewertung und Umsetzung der Information... | - |
| 1.3.3-M2 | MUSS | R02 | Die externen IT-Dienste sind mit dem Schutzbedarf der verarbeiteten Informationswerte abge... | - |
| 1.3.3-S1 | SOLL | R02 | Anforderungen an Beschaffung, Inbetriebnahme und Freigabe im Zusammenhang mit der Nutzung ... | FLAG_INCLUDE_SHOULD |
| 1.3.3-S2 | SOLL | R02 | Ein Verfahren zur Freigabe unter Berücksichtigung des Schutzbedarfs ist etabliert. | FLAG_INCLUDE_SHOULD |
| 1.3.3-S3 | SOLL | R02 | Externe IT-Dienste und ihre Freigabe sind dokumentiert. | FLAG_INCLUDE_SHOULD |
| 1.3.3-S4 | SOLL | R02 | Es wird regelmäßig überprüft, dass nur freigegebene externe IT-Dienste genutzt werden. | FLAG_INCLUDE_SHOULD |
| 1.3.4-M1 | MUSS | R02 | Software wird vor Installation oder Nutzung freigegeben; dabei werden die einschlägigen As... | - |
| 1.3.4-M2 | MUSS | R02 | Die Softwarefreigabe gilt auch für Spezialsoftware wie Wartungswerkzeuge. | - |
| 1.3.4-S1 | SOLL | R02 | Die zu verwaltenden Softwarearten (Firmware, Betriebssysteme, Anwendungen, Bibliotheken, G... | FLAG_INCLUDE_SHOULD |
| 1.3.4-S2 | SOLL | R02 | Repositorys der verwalteten Software existieren. | FLAG_INCLUDE_SHOULD |
| 1.3.4-S3 | SOLL | R02 | Die Software-Repositorys sind gegen unbefugte Manipulation geschützt. | FLAG_INCLUDE_SHOULD |
| 1.3.4-S4 | SOLL | R02 | Die Freigabe von Software wird regelmäßig überprüft. | FLAG_INCLUDE_SHOULD |
| 1.3.4-S5 | SOLL | R02 | Softwareversionen und Patch-Stände sind bekannt. | FLAG_INCLUDE_SHOULD |
| 1.3.4-V1 | SEHR HOCH | R02 | Zusätzliche Anforderungen an die Softwarenutzung (z. B. Kontroll-/Überwachungsbedarf der N... | FLAG_VERY_HIGH_PROTECTION |
| 1.4.1-M1 | MUSS | R03 | Risikobewertungen werden regelmäßig und anlassbezogen durchgeführt. | - |
| 1.4.1-M2 | MUSS | R03 | Informationssicherheitsrisiken werden angemessen bewertet (z. B. Eintrittswahrscheinlichke... | - |
| 1.4.1-M3 | MUSS | R03 | Informationssicherheitsrisiken werden dokumentiert. | - |
| 1.4.1-M4 | MUSS | R03 | Jedem Informationssicherheitsrisiko ist ein Verantwortlicher (Risk Owner) zugeordnet, der ... | - |
| 1.4.1-S1 | SOLL | R03 | Ein Verfahren zur Identifikation, Bewertung und Behandlung von Sicherheitsrisiken ist vorh... | FLAG_INCLUDE_SHOULD |
| 1.4.1-S2 | SOLL | R03 | Kriterien für Bewertung und Behandlung von Sicherheitsrisiken existieren. | FLAG_INCLUDE_SHOULD |
| 1.4.1-S3 | SOLL | R03 | Maßnahmen zur Risikobehandlung und ihre Verantwortlichen sind festgelegt und dokumentiert;... | FLAG_INCLUDE_SHOULD |
| 1.4.1-S4 | SOLL | R03 | Bei Änderungen des Umfelds (z. B. Organisationsstruktur, Standort, Regularien) erfolgt zei... | FLAG_INCLUDE_SHOULD |
| 1.5.1-M1 | MUSS | R03 | Die Einhaltung der Richtlinien wird organisationsweit überprüft. | - |
| 1.5.1-M2 | MUSS | R03 | Informationssicherheitsrichtlinien und -verfahren werden regelmäßig überprüft. | - |
| 1.5.1-M3 | MUSS | R03 | Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt. | - |
| 1.5.1-M4 | MUSS | R03 | Die Einhaltung von Informationssicherheitsanforderungen (z. B. technische Vorgaben) wird r... | - |
| 1.5.1-M5 | MUSS | R03 | Die Ergebnisse der durchgeführten Überprüfungen werden aufgezeichnet und aufbewahrt. | - |
| 1.5.1-S1 | SOLL | R03 | Ein Plan für Inhalt und Rahmenbedingungen (Zeitplan, Umfang, Controls) der durchzuführende... | FLAG_INCLUDE_SHOULD |
| 1.5.2-M1 | MUSS | R03 | Informationssicherheitsüberprüfungen werden durch eine unabhängige und kompetente Stelle r... | - |
| 1.5.2-M2 | MUSS | R03 | Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt. | - |
| 1.5.2-S1 | SOLL | R03 | Die Ergebnisse durchgeführter Überprüfungen werden dokumentiert und der Organisationsleitu... | FLAG_INCLUDE_SHOULD |
| 1.6.1-M1 | MUSS | R04 | Eine Definition für ein meldepflichtiges Sicherheitsereignis oder eine Beobachtung existie... | - |
| 1.6.1-M2 | MUSS | R04 | Angemessene, risikoorientierte Mechanismen zur Meldung von Sicherheitsereignissen sind def... | - |
| 1.6.1-M3 | MUSS | R04 | Angemessene Kanäle zur Kommunikation mit Meldenden existieren. | - |
| 1.6.1-S1 | SOLL | R04 | Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert. | FLAG_INCLUDE_SHOULD |
| 1.6.1-S2 | SOLL | R04 | Verschiedene Meldekanäle je nach wahrgenommener Schwere (Echtzeit für gravierende Ereignis... | FLAG_INCLUDE_SHOULD |
| 1.6.1-S3 | SOLL | R04 | Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden. | FLAG_INCLUDE_SHOULD |
| 1.6.1-S4 | SOLL | R04 | Sicherheitsereignisse können auch durch Externe gemeldet werden; die einschlägigen Aspekte... | FLAG_INCLUDE_SHOULD |
| 1.6.1-S5 | SOLL | R04 | Der Mechanismus und die Information, wie Vorfälle gemeldet werden, sind für alle relevante... | FLAG_INCLUDE_SHOULD |
| 1.6.1-S6 | SOLL | R04 | Ein Rückmeldeverfahren an die Meldenden ist etabliert. | FLAG_INCLUDE_SHOULD |
| 1.6.1-V1 | SEHR HOCH | R04 | Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C... | FLAG_VERY_HIGH_PROTECTION |
| 1.6.2-M1 | MUSS | R04 | Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet. | - |
| 1.6.2-M2 | MUSS | R04 | Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt. | - |
| 1.6.2-M3 | MUSS | R04 | Lessons Learned fließen in die kontinuierliche Verbesserung ein. | - |
| 1.6.2-S1 | SOLL | R04 | Gemeldete Ereignisse werden bei der Bearbeitung kategorisiert (z. B. Personal, physisch, C... | FLAG_INCLUDE_SHOULD |
| 1.6.2-S2 | SOLL | R04 | Verantwortlichkeiten für die Behandlung von Ereignissen je Kategorie sind definiert und zu... | FLAG_INCLUDE_SHOULD |
| 1.6.2-S3 | SOLL | R04 | Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an zuständige Behö... | FLAG_INCLUDE_SHOULD |
| 1.6.2-H1 | HOCH | R04 | Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A) | FLAG_HIGH_PROTECTION |
| 1.6.2-H2 | HOCH | R04 | Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; die einschlägigen Aspekte... | FLAG_HIGH_PROTECTION |
| 1.6.2-H3 | HOCH | R04 | Gesetzliche, regulatorische und vertragliche Meldepflichten sowie zugehörige Kontaktinform... | FLAG_HIGH_PROTECTION |
| 1.6.2-H4 | HOCH | R04 | Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; die einschlägi... | FLAG_HIGH_PROTECTION |
| 1.6.2-H5 | HOCH | R04 | Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; die einschl... | FLAG_HIGH_PROTECTION |
| 1.6.2-V1 | SEHR HOCH | R04 | Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßi... | FLAG_VERY_HIGH_PROTECTION |
| 1.6.3-M1 | MUSS | R04 | Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert und... | - |
| 1.6.3-M2 | MUSS | R04 | Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert ... | - |
| 1.6.3-M3 | MUSS | R04 | Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert. | - |
| 1.6.3-S1 | SOLL | R04 | Methoden zur Erkennung von Krisensituationen sind etabliert; allgemeine Anzeichen und spez... | FLAG_INCLUDE_SHOULD |
| 1.6.3-S2 | SOLL | R04 | Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden. | FLAG_INCLUDE_SHOULD |
| 1.6.3-S3 | SOLL | R04 | Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und relevantem P... | FLAG_INCLUDE_SHOULD |
| 1.6.3-S4 | SOLL | R04 | Ein Krisenstab ist definiert und genehmigt. | FLAG_INCLUDE_SHOULD |
| 1.6.3-S5 | SOLL | R04 | Krisenrichtlinien und -verfahren sind definiert und genehmigt. | FLAG_INCLUDE_SHOULD |
| 1.6.3-S6 | SOLL | R04 | Die Krisenplanung wird regelmäßig überprüft und aktualisiert. | FLAG_INCLUDE_SHOULD |
| 1.6.3-H1 | HOCH | R04 | Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert. | FLAG_HIGH_PROTECTION |
| 1.6.3-H2 | HOCH | R04 | Notwendige Ressourcen und Informationen zur Krisenbewältigung (z. B. Kommunikationsinfrast... | FLAG_HIGH_PROTECTION |
| 1.6.3-H3 | HOCH | R04 | Eine Kommunikationsstrategie für Krisensituationen existiert. (A) | FLAG_HIGH_PROTECTION |
| 1.6.3-H4 | HOCH | R04 | Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewerte... | FLAG_HIGH_PROTECTION |
| 1.6.3-H5 | HOCH | R04 | Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tableto... | FLAG_HIGH_PROTECTION |
| 1.6.3-V1 | SEHR HOCH | R04 | Krisenübungen und Simulationen unter Einbindung aller relevanten Personen, einschließlich ... | FLAG_VERY_HIGH_PROTECTION |
| 2.1.1-M1 | MUSS | R05 | Sensible Arbeitsbereiche und Tätigkeiten sind bestimmt. | - |
| 2.1.1-M2 | MUSS | R05 | Die Anforderungen an Beschäftigte hinsichtlich ihrer Stellenprofile sind bestimmt und erfü... | - |
| 2.1.1-M3 | MUSS | R05 | Die Identität potenzieller Beschäftigter wird verifiziert (z. B. Prüfung von Ausweisdokume... | - |
| 2.1.1-S1 | SOLL | R05 | Die persönliche Eignung potenzieller Beschäftigter wird mit einfachen Methoden überprüft (... | FLAG_INCLUDE_SHOULD |
| 2.1.1-S2 | SOLL | R05 | Eine erweiterte Eignungsprüfung abhängig vom Arbeitsbereich und der Tätigkeit wird durchge... | FLAG_INCLUDE_SHOULD |
| 2.1.2-M1 | MUSS | R05 | Eine Vertraulichkeitsverpflichtung ist in Kraft. | - |
| 2.1.2-M2 | MUSS | R05 | Eine Verpflichtung zur Einhaltung der Informationssicherheitsrichtlinien ist in Kraft. | - |
| 2.1.2-S1 | SOLL | R05 | Eine über den Arbeitsvertrag hinausgehende Vertraulichkeitsverpflichtung ist in Kraft. | FLAG_INCLUDE_SHOULD |
| 2.1.2-S2 | SOLL | R05 | Informationssicherheitsaspekte werden in den Arbeitsverträgen der Beschäftigten berücksich... | FLAG_INCLUDE_SHOULD |
| 2.1.2-S3 | SOLL | R05 | Ein Verfahren zum Umgang mit Verstößen gegen diese Verpflichtungen ist beschrieben. | FLAG_INCLUDE_SHOULD |
| 2.1.3-M1 | MUSS | R05 | Beschäftigte werden geschult und sensibilisiert. | - |
| 2.1.3-S1 | SOLL | R05 | Ein Konzept für Sensibilisierung und Schulung der Beschäftigten ist erstellt. | FLAG_INCLUDE_SHOULD |
| 2.1.3-S2 | SOLL | R05 | Zielgruppen für Schulungs- und Sensibilisierungsmaßnahmen (z. B. Führungskräfte, Administr... | FLAG_INCLUDE_SHOULD |
| 2.1.3-S3 | SOLL | R05 | Das Konzept ist durch die verantwortliche Leitung genehmigt. | FLAG_INCLUDE_SHOULD |
| 2.1.3-S4 | SOLL | R05 | Schulungs- und Sensibilisierungsmaßnahmen werden regelmäßig und anlassbezogen durchgeführt... | FLAG_INCLUDE_SHOULD |
| 2.1.3-S5 | SOLL | R05 | Die Teilnahme an Schulungs- und Sensibilisierungsmaßnahmen wird dokumentiert. | FLAG_INCLUDE_SHOULD |
| 2.1.3-S6 | SOLL | R05 | Ansprechpartner für Informationssicherheit sind den Beschäftigten bekannt. | FLAG_INCLUDE_SHOULD |
| 2.1.4-M1 | MUSS | R06 | Die Anforderungen an mobiles Arbeiten sind bestimmt und erfüllt; dabei werden die einschlä... | - |
| 2.1.4-S1 | SOLL | R06 | Die einschlägigen Aspekte des mobilen Arbeitens werden berücksichtigt. | FLAG_INCLUDE_SHOULD |
| 2.1.4-S2 | SOLL | R06 | Sensibilisierung der Beschäftigten. | FLAG_INCLUDE_SHOULD |
| 2.1.4-H1 | HOCH | R06 | Schutzmaßnahmen gegen Abhören und Einsehen sind umgesetzt. (C) | FLAG_HIGH_PROTECTION |
| 3.1.1-M1 | MUSS | R07 | Ein Sicherheitszonenkonzept einschließlich zugehöriger Schutzmaßnahmen auf Basis der Anfor... | - |
| 3.1.1-M2 | MUSS | R07 | Die definierten Schutzmaßnahmen sind umgesetzt. | - |
| 3.1.1-M3 | MUSS | R07 | Der Verhaltenskodex für Sicherheitszonen ist allen beteiligten Personen bekannt. | - |
| 3.1.1-S1 | SOLL | R07 | Verfahren für die Vergabe und den Entzug von Zutrittsrechten sind etabliert. | FLAG_INCLUDE_SHOULD |
| 3.1.1-S2 | SOLL | R07 | Richtlinien für das Besuchermanagement (einschließlich Registrierung und Begleitung von Be... | FLAG_INCLUDE_SHOULD |
| 3.1.1-S3 | SOLL | R07 | Richtlinien für das Mitführen und Nutzen mobiler IT-Geräte und Datenträger (z. B. Registri... | FLAG_INCLUDE_SHOULD |
| 3.1.1-S4 | SOLL | R07 | Netzwerk-/Infrastrukturkomponenten (eigene oder Kundennetze) sind gegen unbefugten Zugriff... | FLAG_INCLUDE_SHOULD |
| 3.1.1-S5 | SOLL | R07 | Externe Liegenschaften zur Speicherung/Verarbeitung von Informationswerten sind im Zonenko... | FLAG_INCLUDE_SHOULD |
| 3.1.1-H1 | HOCH | R07 | Schutzmaßnahmen gegen einfaches Abhören und Einsehen sind umgesetzt. (C) | FLAG_HIGH_PROTECTION |
| 3.1.4-M1 | MUSS | R06 | Die Anforderungen an mobile IT-Geräte und mobile Datenträger sind bestimmt und erfüllt; da... | - |
| 3.1.4-S1 | SOLL | R06 | Registrierung der IT-Geräte. | FLAG_INCLUDE_SHOULD |
| 3.1.4-H1 | HOCH | R06 | Generelle Verschlüsselung mobiler Datenträger bzw. der darauf gespeicherten Informationswe... | FLAG_HIGH_PROTECTION |
| 4.1.1-M1 | MUSS | R08 | Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus ... | - |
| 4.1.1-S1 | SOLL | R08 | Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden. | FLAG_INCLUDE_SHOULD |
| 4.1.1-H1 | HOCH | R08 | Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall... | FLAG_HIGH_PROTECTION |
| 4.1.2-M1 | MUSS | R08 | Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewähl... | - |
| 4.1.2-M2 | MUSS | R08 | Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt. | - |
| 4.1.2-S1 | SOLL | R08 | Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevante... | FLAG_INCLUDE_SHOULD |
| 4.1.2-S2 | SOLL | R08 | Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktike... | FLAG_INCLUDE_SHOULD |
| 4.1.2-S3 | SOLL | R08 | Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. Privileged A... | FLAG_INCLUDE_SHOULD |
| 4.1.2-H1 | HOCH | R08 | Abhängig von der Risikobewertung sind Authentifizierung und Zugangskontrolle durch ergänze... | FLAG_HIGH_PROTECTION |
| 4.1.2-V1 | SEHR HOCH | R08 | Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Auth... | FLAG_VERY_HIGH_PROTECTION |
| 4.1.3-M1 | MUSS | R08 | Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt. | - |
| 4.1.3-M2 | MUSS | R08 | Eindeutige und personalisierte Benutzerkonten werden verwendet. | - |
| 4.1.3-M3 | MUSS | R08 | Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollzi... | - |
| 4.1.3-M4 | MUSS | R08 | Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei ... | - |
| 4.1.3-M5 | MUSS | R08 | Benutzerkonten werden regelmäßig überprüft. | - |
| 4.1.3-M6 | MUSS | R08 | Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt. | - |
| 4.1.3-M7 | MUSS | R08 | Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei wer... | - |
| 4.1.3-S1 | SOLL | R08 | Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genut... | FLAG_INCLUDE_SHOULD |
| 4.1.3-S10 | SOLL | R08 | Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S2 | SOLL | R08 | Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Spe... | FLAG_INCLUDE_SHOULD |
| 4.1.3-S3 | SOLL | R08 | Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S4 | SOLL | R08 | Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip)... | FLAG_INCLUDE_SHOULD |
| 4.1.3-S5 | SOLL | R08 | Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S6 | SOLL | R08 | Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S7 | SOLL | R08 | Die Verwendung von Standardpasswörtern wird technisch verhindert. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S8 | SOLL | R08 | Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher. | FLAG_INCLUDE_SHOULD |
| 4.1.3-S9 | SOLL | R08 | Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Ku... | FLAG_INCLUDE_SHOULD |
| 4.2.1-M1 | MUSS | R08 | Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und ... | - |
| 4.2.1-M2 | MUSS | R08 | Die für normale und privilegierte Benutzerkonten sowie technische Konten vergebenen Zugrif... | - |
| 4.2.1-S1 | SOLL | R08 | Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet. | FLAG_INCLUDE_SHOULD |
| 4.2.1-S2 | SOLL | R08 | Autorisierungsrollen werden verwendet. | FLAG_INCLUDE_SHOULD |
| 4.2.1-S3 | SOLL | R08 | Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich ... | FLAG_INCLUDE_SHOULD |
| 4.2.1-S4 | SOLL | R08 | Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte. | FLAG_INCLUDE_SHOULD |
| 4.2.1-S5 | SOLL | R08 | Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisie... | FLAG_INCLUDE_SHOULD |
| 4.2.1-H1 | HOCH | R08 | Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmig... | FLAG_HIGH_PROTECTION |
| 4.2.1-V1 | SEHR HOCH | R08 | Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unb... | FLAG_VERY_HIGH_PROTECTION |
| 4.2.1-V2 | SEHR HOCH | R08 | Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C... | FLAG_VERY_HIGH_PROTECTION |
| 5.1.1-M1 | MUSS | R09 | Alle eingesetzten kryptografischen Verfahren (z. B. Verschlüsselung, Signatur, Hash-Algori... | - |
| 5.1.1-S1 | SOLL | R09 | Ein Konzept für den Einsatz von Kryptografie ist definiert und umgesetzt; dabei werden die... | FLAG_INCLUDE_SHOULD |
| 5.1.1-H1 | HOCH | R09 | Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) sind bestimm... | FLAG_HIGH_PROTECTION |
| 5.1.2-M1 | MUSS | R09 | Die zur Informationsübertragung genutzten Netzdienste sind identifiziert und dokumentiert. | - |
| 5.1.2-M2 | MUSS | R09 | Richtlinien und Verfahren entsprechend den Klassifizierungsanforderungen für die Nutzung v... | - |
| 5.1.2-M3 | MUSS | R09 | Maßnahmen zum Schutz übertragener Inhalte gegen unbefugten Zugriff sind umgesetzt. | - |
| 5.1.2-S1 | SOLL | R09 | Maßnahmen zur Sicherstellung korrekter Adressierung und korrekter Informationsübertragung ... | FLAG_INCLUDE_SHOULD |
| 5.1.2-S2 | SOLL | R09 | Elektronischer Datenaustausch erfolgt mittels Inhalts- oder Transportverschlüsselung entsp... | FLAG_INCLUDE_SHOULD |
| 5.1.2-S3 | SOLL | R09 | Fernzugriffsverbindungen zum Netzwerk der Organisation verfügen über angemessene Sicherhei... | FLAG_INCLUDE_SHOULD |
| 5.1.2-H1 | HOCH | R09 | Informationen werden verschlüsselt übertragen (mindestens Transportverschlüsselung) oder d... | FLAG_HIGH_PROTECTION |
| 5.1.2-V1 | SEHR HOCH | R09 | Informationen werden inhaltsverschlüsselt übertragen. (C) | FLAG_VERY_HIGH_PROTECTION |
| 5.2.1-M1 | MUSS | R10 | Informationssicherheitsanforderungen für Änderungen an Organisation, Geschäftsprozessen un... | - |
| 5.2.1-S1 | SOLL | R10 | Ein formales Genehmigungsverfahren ist etabliert. | FLAG_INCLUDE_SHOULD |
| 5.2.1-S2 | SOLL | R10 | Die möglichen Auswirkungen von Änderungen auf die Informationssicherheit werden bewertet. | FLAG_INCLUDE_SHOULD |
| 5.2.1-S3 | SOLL | R10 | Änderungen mit Auswirkung auf die Informationssicherheit werden geplant und getestet. | FLAG_INCLUDE_SHOULD |
| 5.2.1-S4 | SOLL | R10 | Verfahren zum Rückfall (Fallback) in Fehlerfällen werden berücksichtigt. | FLAG_INCLUDE_SHOULD |
| 5.2.1-H1 | HOCH | R10 | Die Einhaltung der Informationssicherheitsanforderungen wird während und nach den Änderung... | FLAG_HIGH_PROTECTION |
| 5.2.2-M1 | MUSS | R10 | Die IT-Systeme wurden einer Risikobewertung unterzogen, um die Notwendigkeit ihrer Trennun... | - |
| 5.2.2-M2 | MUSS | R10 | Eine Segmentierung ist auf Basis der Ergebnisse der Risikoanalyse umgesetzt. | - |
| 5.2.2-S1 | SOLL | R10 | Die Anforderungen an Entwicklungs- und Testumgebungen sind bestimmt und erfüllt; dabei wer... | FLAG_INCLUDE_SHOULD |
| 5.2.3-M1 | MUSS | R10 | Anforderungen zum Schutz vor Schadsoftware sind bestimmt. | - |
| 5.2.3-M2 | MUSS | R10 | Technische und organisatorische Maßnahmen zum Schutz vor Schadsoftware sind definiert und ... | - |
| 5.2.3-S1 | SOLL | R10 | Unnötige Netzwerkdienste sind deaktiviert. | FLAG_INCLUDE_SHOULD |
| 5.2.3-S2 | SOLL | R10 | Der Zugriff auf Netzwerkdienste ist durch geeignete Schutzmaßnahmen auf das Notwendige bes... | FLAG_INCLUDE_SHOULD |
| 5.2.3-S3 | SOLL | R10 | Schutzsoftware gegen Schadsoftware ist installiert und wird regelmäßig automatisch aktuali... | FLAG_INCLUDE_SHOULD |
| 5.2.3-S4 | SOLL | R10 | Empfangene Dateien und Software werden vor der Ausführung automatisch auf Schadsoftware ge... | FLAG_INCLUDE_SHOULD |
| 5.2.3-S5 | SOLL | R10 | Der gesamte Datenbestand aller Systeme wird regelmäßig auf Schadsoftware geprüft. | FLAG_INCLUDE_SHOULD |
| 5.2.3-S6 | SOLL | R10 | Über zentrale Gateways übertragene Daten (z. B. E-Mail, Internet, Fremdnetze) werden autom... | FLAG_INCLUDE_SHOULD |
| 5.2.3-S7 | SOLL | R10 | Maßnahmen, die verhindern, dass Schutzsoftware durch Nutzer deaktiviert oder verändert wir... | FLAG_INCLUDE_SHOULD |
| 5.2.3-S8 | SOLL | R10 | Für IT-Systeme ohne Schutzsoftware sind alternative Maßnahmen umgesetzt (z. B. besondere R... | FLAG_INCLUDE_SHOULD |
| 5.2.4-M1 | MUSS | R10 | Informationssicherheitsanforderungen an den Umgang mit Ereignisprotokollen sind bestimmt u... | - |
| 5.2.4-M2 | MUSS | R10 | Sicherheitsrelevante Anforderungen an die Protokollierung von Aktivitäten von Administrato... | - |
| 5.2.4-M3 | MUSS | R10 | Die eingesetzten IT-Systeme werden hinsichtlich der Notwendigkeit der Protokollierung bewe... | - |
| 5.2.4-M4 | MUSS | R10 | Bei Nutzung externer IT-Dienste werden Informationen zu den Überwachungsmöglichkeiten eing... | - |
| 5.2.4-M5 | MUSS | R10 | Ereignisprotokolle werden regelmäßig auf Richtlinienverstöße und auffällige Probleme geprü... | - |
| 5.2.4-S1 | SOLL | R10 | Ein Verfahren zur Eskalation relevanter Ereignisse an die verantwortliche Stelle ist defin... | FLAG_INCLUDE_SHOULD |
| 5.2.4-S2 | SOLL | R10 | Ereignisprotokolle (Inhalt und Metadaten) sind gegen Veränderung geschützt (z. B. durch ei... | FLAG_INCLUDE_SHOULD |
| 5.2.4-S3 | SOLL | R10 | Eine angemessene Überwachung und Aufzeichnung aller informationssicherheitsrelevanten Akti... | FLAG_INCLUDE_SHOULD |
| 5.2.4-H1 | HOCH | R10 | Sicherheitsrelevante Anforderungen an den Umgang mit Ereignisprotokollen, z. B. vertraglic... | FLAG_HIGH_PROTECTION |
| 5.2.4-H2 | HOCH | R10 | Ereignisse zu Auf- und Abbau von Fernzugriffssitzungen (z. B. Fernwartung) werden protokol... | FLAG_HIGH_PROTECTION |
| 5.2.4-V1 | SEHR HOCH | R10 | Protokollierung jedes Zugriffs auf Daten mit sehr hohem Schutzbedarf, soweit technisch mac... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.5-M1 | MUSS | R10 | Informationen über technische Schwachstellen der eingesetzten IT-Systeme werden erhoben (z... | - |
| 5.2.5-M2 | MUSS | R10 | Potenziell betroffene IT-Systeme und Software werden identifiziert und das durch die Schwa... | - |
| 5.2.5-M3 | MUSS | R10 | Risiken aus Schwachstellen werden behandelt. | - |
| 5.2.5-S1 | SOLL | R10 | Ein angemessenes Patch-Management ist definiert und umgesetzt (z. B. Patch-Test und -Insta... | FLAG_INCLUDE_SHOULD |
| 5.2.5-S2 | SOLL | R10 | Risikominimierende Maßnahmen werden bei Bedarf umgesetzt. | FLAG_INCLUDE_SHOULD |
| 5.2.5-S3 | SOLL | R10 | Die erfolgreiche Installation von Patches wird in geeigneter Weise verifiziert. | FLAG_INCLUDE_SHOULD |
| 5.2.6-M1 | MUSS | R10 | Anforderungen an die Prüfung (Audit) von IT-Systemen oder -Diensten sind bestimmt. | - |
| 5.2.6-M2 | MUSS | R10 | Der Umfang der Systemprüfung wird rechtzeitig festgelegt. | - |
| 5.2.6-M3 | MUSS | R10 | System- oder Dienstprüfungen werden mit Betreiber und Nutzern der IT-Systeme/-Dienste abge... | - |
| 5.2.6-M4 | MUSS | R10 | Die Ergebnisse von System-/Dienstprüfungen werden nachvollziehbar gespeichert und der zust... | - |
| 5.2.6-M5 | MUSS | R10 | Aus den Ergebnissen werden Maßnahmen abgeleitet und in angemessener Frist umgesetzt. | - |
| 5.2.6-S1 | SOLL | R10 | System- und Dienstprüfungen werden unter Berücksichtigung möglicher Sicherheitsrisiken (z.... | FLAG_INCLUDE_SHOULD |
| 5.2.6-S2 | SOLL | R10 | Regelmäßige System- oder Dienstprüfungen werden durchgeführt; dabei werden die einschlägig... | FLAG_INCLUDE_SHOULD |
| 5.2.6-S3 | SOLL | R10 | Innerhalb einer angemessenen Frist nach Abschluss der Prüfung wird ein Bericht erstellt. | FLAG_INCLUDE_SHOULD |
| 5.2.6-H1 | HOCH | R10 | Für kritische IT-Systeme/-Dienste wurden zusätzliche Prüfanforderungen identifiziert und w... | FLAG_HIGH_PROTECTION |
| 5.2.6-V1 | SEHR HOCH | R10 | IT-Systeme und -Dienste werden regelmäßig auf Schwachstellen gescannt. Für nicht scanbare ... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.7-M1 | MUSS | R10 | Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und erfüllt... | - |
| 5.2.7-M2 | MUSS | R10 | Anforderungen an die Netzsegmentierung sind bestimmt und erfüllt. | - |
| 5.2.7-S1 | SOLL | R10 | Verfahren für das Management und die Steuerung von Netzwerken sind definiert. | FLAG_INCLUDE_SHOULD |
| 5.2.7-S2 | SOLL | R10 | Für eine risikobasierte Netzsegmentierung werden die einschlägigen Aspekte berücksichtigt. | FLAG_INCLUDE_SHOULD |
| 5.2.7-H1 | HOCH | R10 | Erweiterte Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt ... | FLAG_HIGH_PROTECTION |
| 5.2.8-M1 | MUSS | R04 | Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt. | - |
| 5.2.8-M2 | MUSS | R04 | Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung dieser IT-Die... | - |
| 5.2.8-S1 | SOLL | R04 | Kritische IT-Systeme sind identifiziert; dabei werden die einschlägigen Aspekte berücksich... | FLAG_INCLUDE_SHOULD |
| 5.2.8-S2 | SOLL | R04 | Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert. | FLAG_INCLUDE_SHOULD |
| 5.2.8-S3 | SOLL | R04 | Die Kontinuitätsplanung umfasst mindestens (D)DoS-Angriffe, erfolgreiche Ransomware-Angrif... | FLAG_INCLUDE_SHOULD |
| 5.2.8-H1 | HOCH | R04 | Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (Recovery Time Objective) für die... | FLAG_HIGH_PROTECTION |
| 5.2.8-H2 | HOCH | R04 | Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen... | FLAG_HIGH_PROTECTION |
| 5.2.8-H3 | HOCH | R04 | Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit... | FLAG_HIGH_PROTECTION |
| 5.2.8-H4 | HOCH | R04 | Die Kontinuitätsplanung wird regelmäßig getestet, inkl. vollständiger Wiederherstellung in... | FLAG_HIGH_PROTECTION |
| 5.2.8-H5 | HOCH | R04 | Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste und Informationen is... | FLAG_HIGH_PROTECTION |
| 5.2.8-H6 | HOCH | R04 | Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugte Veränderu... | FLAG_HIGH_PROTECTION |
| 5.2.8-H7 | HOCH | R04 | Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugten Zugriff ... | FLAG_HIGH_PROTECTION |
| 5.2.8-V1 | SEHR HOCH | R04 | Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister a... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.8-V2 | SEHR HOCH | R04 | Die Fortführung wesentlicher Kern- und Geschäftsfunktionen mit minimalem oder keinem Verlu... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.8-V3 | SEHR HOCH | R04 | Die Kontinuitätsplanung wird regelmäßig getestet. Testszenarien, Ergebnisse und Lessons Le... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.9-M1 | MUSS | R10 | Backup-Konzepte existieren für relevante IT-Systeme. Angemessene Schutzmaßnahmen für Vertr... | - |
| 5.2.9-M2 | MUSS | R10 | Wiederherstellungskonzepte existieren für relevante IT-Dienste. | - |
| 5.2.9-S1 | SOLL | R10 | Für jeden relevanten IT-Dienst existiert ein Backup- und Wiederherstellungskonzept. Abhäng... | FLAG_INCLUDE_SHOULD |
| 5.2.9-H1 | HOCH | R10 | Backup- und Wiederherstellungskonzepte werden methodisch in regelmäßigen Abständen überprü... | FLAG_HIGH_PROTECTION |
| 5.2.9-H2 | HOCH | R10 | Die grundsätzliche Wiederherstellbarkeit wird berücksichtigt und getestet (z. B. Stichprob... | FLAG_HIGH_PROTECTION |
| 5.2.9-V1 | SEHR HOCH | R10 | (Zusätzliche) Backups werden über Offline-Verfahren, unveränderliche (immutable) Backups o... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.9-V2 | SEHR HOCH | R10 | Wiederherstellungsverfahren werden methodisch in regelmäßigen Abständen technisch getestet... | FLAG_VERY_HIGH_PROTECTION |
| 5.2.9-V3 | SEHR HOCH | R10 | Geografische Redundanz wird in Backup- und Wiederherstellungskonzepten berücksichtigt. (A) | FLAG_VERY_HIGH_PROTECTION |
| 5.3.1-M1 | MUSS | R11 | Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanford... | - |
| 5.3.1-M2 | MUSS | R11 | Die mit Beschaffung oder Erweiterung von IT-Diensten und -Komponenten verbundenen Informat... | - |
| 5.3.1-M3 | MUSS | R11 | Informationssicherheitsanforderungen im Zusammenhang mit Änderungen an entwickelten IT-Die... | - |
| 5.3.1-M4 | MUSS | R11 | Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen ... | - |
| 5.3.1-S1 | SOLL | R11 | Anforderungsspezifikationen werden erstellt; dabei werden die einschlägigen Aspekte berück... | FLAG_INCLUDE_SHOULD |
| 5.3.1-S2 | SOLL | R11 | Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft. | FLAG_INCLUDE_SHOULD |
| 5.3.1-S3 | SOLL | R11 | Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft. | FLAG_INCLUDE_SHOULD |
| 5.3.1-S4 | SOLL | R11 | Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden (ggf. Anonymis... | FLAG_INCLUDE_SHOULD |
| 5.3.1-S5 | SOLL | R11 | Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdat... | FLAG_INCLUDE_SHOULD |
| 5.3.1-V1 | SEHR HOCH | R11 | Die Sicherheit zweckgebauter oder wesentlich angepasster Software wird bei Inbetriebnahme,... | FLAG_VERY_HIGH_PROTECTION |
| 5.3.2-M1 | MUSS | R11 | Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt. | - |
| 5.3.2-S1 | SOLL | R11 | Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt. | FLAG_INCLUDE_SHOULD |
| 5.3.2-S2 | SOLL | R11 | Die Anforderungen werden in Form von SLAs vereinbart. | FLAG_INCLUDE_SHOULD |
| 5.3.2-S3 | SOLL | R11 | Angemessene Redundanzlösungen sind umgesetzt. | FLAG_INCLUDE_SHOULD |
| 5.3.2-H1 | HOCH | R11 | Verfahren zur Überwachung der Qualität des Netzverkehrs (z. B. Traffic-Flow-Analysen, Verf... | FLAG_HIGH_PROTECTION |
| 5.3.3-S1 | SOLL | R11 | Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vert... | FLAG_INCLUDE_SHOULD |
| 5.3.4-M1 | MUSS | R12 | Eine wirksame Trennung (z. B. Mandantentrennung) verhindert den Zugriff unbefugter Nutzer ... | - |
| 5.3.4-S1 | SOLL | R12 | Das Trennungskonzept des Anbieters ist dokumentiert und an Änderungen angepasst; dabei wer... | FLAG_INCLUDE_SHOULD |
| 5.3.4-KI-M1 | MUSS | R12 | Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutz... | - |
| 5.3.4-KI-M2 | MUSS | R12 | Die Eingabe vertraulicher oder personenbezogener Informationen in nicht freigegebene KI-Di... | - |
| 5.3.4-KI-M3 | MUSS | R12 | Bei freigegebenen KI-Diensten ist geklärt und vertraglich sichergestellt, dass Eingaben ni... | - |
| 5.3.4-KI-S1 | SOLL | R12 | Ergebnisse von KI-Diensten werden vor geschäftskritischer Verwendung geprüft (Human-in-the... | FLAG_INCLUDE_SHOULD |
| 6.1.1-M1 | MUSS | R13 | Auftragnehmer und Partner werden einer Sicherheitsrisikobewertung unterzogen. | - |
| 6.1.1-M2 | MUSS | R13 | Ein angemessenes Informationssicherheitsniveau wird durch vertragliche Vereinbarungen mit ... | - |
| 6.1.1-M3 | MUSS | R13 | Sofern zutreffend, werden vertragliche Vereinbarungen mit Auftraggebern/Kunden an Auftragn... | - |
| 6.1.1-S1 | SOLL | R13 | Auftragnehmer und Partner sind vertraglich verpflichtet, Anforderungen an ein angemessenes... | FLAG_INCLUDE_SHOULD |
| 6.1.1-S2 | SOLL | R13 | Leistungsberichte und Dokumente von Auftragnehmern und Partnern werden geprüft. | FLAG_INCLUDE_SHOULD |
| 6.1.1-H1 | HOCH | R13 | Es wird nachgewiesen, dass das Informationssicherheitsniveau des Lieferanten dem Schutzbed... | FLAG_HIGH_PROTECTION |
| 6.1.1-H2 | HOCH | R13 | Der Grad der Erfüllung geforderter Nachweise durch den Lieferanten wird dokumentiert, rege... | FLAG_HIGH_PROTECTION |
| 6.1.1-H3 | HOCH | R13 | Die Einhaltung vertraglicher Vereinbarungen durch den Lieferanten wird geprüft, dokumentie... | FLAG_HIGH_PROTECTION |
| 6.1.1-V1 | SEHR HOCH | R13 | Das angemessene Informationssicherheitsniveau sollte durch ein Drittparteien-Audit (angeme... | FLAG_VERY_HIGH_PROTECTION |
| 6.1.1-V2 | SEHR HOCH | R13 | Vertragliche Verpflichtungen gegenüber Kunden zur Transparenz von Lieferkettenrisiken werd... | FLAG_VERY_HIGH_PROTECTION |
| 6.1.2-M1 | MUSS | R13 | Die Vertraulichkeitsanforderungen sind bestimmt und erfüllt. | - |
| 6.1.2-M2 | MUSS | R13 | Anforderungen und Verfahren zur Anwendung von Vertraulichkeitsvereinbarungen sind allen Pe... | - |
| 6.1.2-M3 | MUSS | R13 | Gültige Vertraulichkeitsvereinbarungen werden vor der Weitergabe schutzbedürftiger Informa... | - |
| 6.1.2-M4 | MUSS | R13 | Die Anforderungen und Verfahren zur Nutzung von Vertraulichkeitsvereinbarungen und zum Umg... | - |
| 6.1.2-S1 | SOLL | R13 | Vorlagen für Vertraulichkeitsvereinbarungen sind vorhanden und auf rechtliche Anwendbarkei... | FLAG_INCLUDE_SHOULD |
| 6.1.2-S2 | SOLL | R13 | Vertraulichkeitsvereinbarungen umfassen beteiligte Personen/Organisationen, Art der Inform... | FLAG_INCLUDE_SHOULD |
| 6.1.2-S3 | SOLL | R13 | Vertraulichkeitsvereinbarungen enthalten Regelungen zum Umgang mit schutzbedürftigen Infor... | FLAG_INCLUDE_SHOULD |
| 6.1.2-S4 | SOLL | R13 | Möglichkeiten zum Nachweis der Einhaltung (z. B. Prüfung durch unabhängige Dritte oder Aud... | FLAG_INCLUDE_SHOULD |
| 6.1.2-S5 | SOLL | R13 | Ein Prozess zur Überwachung der Gültigkeitsdauer temporärer Vertraulichkeitsvereinbarungen... | FLAG_INCLUDE_SHOULD |
| 6.1.3-M1 | MUSS | R13 | Die betroffenen IT-Dienste sind identifiziert. | - |
| 6.1.3-M2 | MUSS | R13 | Die für den IT-Dienst relevanten Sicherheitsanforderungen sind bestimmt. | - |
| 6.1.3-M3 | MUSS | R13 | Die für die Umsetzung der Anforderung verantwortliche Organisation ist definiert und sich ... | - |
| 6.1.3-M4 | MUSS | R13 | Mechanismen für geteilte Verantwortlichkeiten sind spezifiziert und umgesetzt. | - |
| 6.1.3-M5 | MUSS | R13 | Die verantwortliche Organisation erfüllt ihre jeweiligen Verantwortlichkeiten. | - |
| 6.1.3-S1 | SOLL | R13 | Bei IT-Diensten ist die Konfiguration auf Basis der notwendigen Sicherheitsanforderungen k... | FLAG_INCLUDE_SHOULD |
| 6.1.3-S2 | SOLL | R13 | Das verantwortliche Personal ist angemessen geschult. | FLAG_INCLUDE_SHOULD |
| 6.1.3-H1 | HOCH | R13 | Eine Liste der betroffenen IT-Dienste und der jeweils verantwortlichen IT-Dienstleister ex... | FLAG_HIGH_PROTECTION |
| 6.1.3-H2 | HOCH | R13 | Die Anwendbarkeit der ISA-Controls wurde bewertet und dokumentiert. (C, I, A) | FLAG_HIGH_PROTECTION |
| 6.1.3-H3 | HOCH | R13 | Die Dienstkonfiguration ist in die regelmäßigen Sicherheitsbewertungen einbezogen. (C, I, ... | FLAG_HIGH_PROTECTION |
| 6.1.3-H4 | HOCH | R13 | Es wird nachgewiesen, dass die IT-Dienstleister ihre Verantwortung erfüllen. (C, I, A) | FLAG_HIGH_PROTECTION |
| 6.1.3-H5 | HOCH | R13 | Die Integration in lokale Schutzmaßnahmen (z. B. sichere Authentifizierungsmechanismen) is... | FLAG_HIGH_PROTECTION |
| 7.1.1-M1 | MUSS | R14 | Rechtliche, regulatorische und vertragliche Vorgaben mit Relevanz für die Informationssich... | - |
| 7.1.1-M2 | MUSS | R14 | Richtlinien zur Einhaltung der Vorgaben sind definiert, umgesetzt und den verantwortlichen... | - |
| 7.1.1-S1 | SOLL | R14 | Die Integrität von Aufzeichnungen entsprechend rechtlichen, regulatorischen und vertraglic... | FLAG_INCLUDE_SHOULD |
| 7.1.2-M1 | MUSS | R14 | Rechtliche und vertragliche Informationssicherheitsanforderungen an Verfahren und Prozesse... | - |
| 7.1.2-M2 | MUSS | R14 | Regelungen zur Einhaltung rechtlicher und vertraglicher Anforderungen an den Schutz person... | - |
| 7.1.2-M3 | MUSS | R14 | Prozesse und Verfahren zum Schutz personenbezogener Daten sind im Informationssicherheits-... | - |
## Hinweis zu ISA-Quelldubletten
Die ISA 2027 enthält im Quelltext **4 doppelte HOCH-Zeilen** (1.6.3 dreifach, 5.2.9 einfach), die inhaltlich identisch mit bereits enthaltenen Anforderungen sind (z. B. Krisenszenarien/-ressourcen/-tests mit und ohne Zusatz „The following aspects are considered"). Diese wurden **konsolidiert**, nicht dupliziert: 316 eindeutige ISA-Zeilen ergeben **312 eindeutige Anforderungen** bei 100 % inhaltlicher Abdeckung. Details siehe `mapping.json` → `meta.isa_quelldubletten`.
seed/isms-vorlagenpaket-v2/Nachweisregister_zentral.md
+47
View File
@@ -0,0 +1,47 @@
# Zentrales Nachweisregister – ISMS {{ORG_NAME}}
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Nachweisregister (gilt für alle Richtlinien) |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
| Verantwortlich | {{ROLE_ISB}} |
## Zweck
Dieses Dokument bündelt **alle Nachweise** für das ISMS an einer Stelle. Die einzelnen Richtlinien enthalten keine Nachweislisten, sondern verweisen hierauf ({{LINK:NACHWEISREGISTER}}). Register mit laufenden Datensätzen (Asset-Inventar, Risikoregister, Lieferanten-/NDA-Verzeichnis, Awareness-Nachweise, Verzeichnis der Verarbeitungstätigkeiten) werden in **{{TOOL_NAME}}** gepflegt; dieses Register verweist darauf.
Die feingranulare Zuordnung Nachweis ↔ einzelne MUSS/SOLL-Anforderung erfolgt über `mapping.json` (Hidden-Anker `REQ`/`IMPL`) und ist im Lesemodus nicht sichtbar. Das Tool erzeugt daraus je Anforderung einen Nachweis-Link.
## Nachweisübersicht
| # | Richtlinie | Nachweis | Quelle | Verantwortlich | Turnus |
|---|-----------|----------|--------|----------------|--------|
| 1 | {{LINK:L00}} | Freigegebene, versionierte IS-Leitlinie inkl. Kommunikationsbeleg | Dok | {{ROLE_MANAGEMENT}} | {{REVIEW_CYCLE}} |
| 2 | {{LINK:R01}} | ISMS-Scope, Rollen-/Verantwortungsmatrix, Managementbewertung | Tool/Dok | {{ROLE_ISB}} | jährlich |
| 3 | {{LINK:R02}} | Asset-Inventar & Klassifizierungsmatrix; Liste zugelassener Hard-/Software | Tool | {{ROLE_IT_LEAD}} | laufend |
| 4 | {{LINK:R03}} | Risikoregister & Behandlungsplan; interne/unabhängige Prüfberichte | Tool/Dok | {{ROLE_ISB}} | ≤ jährlich |
| 5 | {{LINK:R04}} | Incident-Aufzeichnungen; Krisen-/Notfallplan; Wiederanlauftests | Tool/Dok | {{ROLE_ISB}} | laufend |
| 6 | {{LINK:R05}} | Vertraulichkeitsverpflichtungen; Schulungs-/Awareness-Nachweise | Tool | {{ROLE_HR_LEAD}} | bei Eintritt / jährlich |
| 7 | {{LINK:R06}} | Regelung & Genehmigungen mobiles Arbeiten / mobile Geräte | Dok/Tool | {{ROLE_ISB}} | laufend |
| 8 | {{LINK:R07}} | Zutrittskonzept, Zonenplan, Zutrittsprotokolle | Dok | {{ROLE_IT_LEAD}} | laufend |
| 9 | {{LINK:R08}} | Berechtigungskonzept & Rezertifizierungsnachweise | Tool | {{ROLE_IT_LEAD}} | ≤ jährlich |
| 10 | {{LINK:R09}} | Kryptokonzept, Schlüssel-/Zertifikatsverwaltung | Dok | {{ROLE_IT_LEAD}} | laufend |
| 11 | {{LINK:R10}} | Change-/Patch-/Schwachstellenberichte, Malware-Status, Logging, Backup-/Recovery-Tests | Tool/Aufz. | {{ROLE_IT_LEAD}} | laufend |
| 12 | {{LINK:R11}} | Sicherheitsanforderungen Beschaffung/Entwicklung; Löschnachweise | Dok/Aufz. | {{ROLE_IT_LEAD}} | laufend |
| 13 | {{LINK:R12}} | Freigabeliste Cloud-/KI-Dienste, Segregations-/Datenflussnachweise | Tool/Dok | {{ROLE_ISB}} | laufend |
| 14 | {{LINK:R13}} | Lieferantenverzeichnis, NDAs, Verantwortungsabgrenzung | Tool | {{ROLE_ISB}} | laufend |
| 15 | {{LINK:R14}} | Compliance-/Rechtsregister; Verzeichnis der Verarbeitungstätigkeiten | Tool | {{ROLE_DPO}} | ≤ jährlich |
| 16 | {{LINK:VA-22}} | Kennzahlenblatt mit Zielwerten, Verantwortlichen und Messwerten je Periode | Tool | {{ROLE_ISB}} | {{MGMT_REVIEW_CYCLE}} |
| 17 | {{LINK:VA-22}} | Protokoll der Managementbewertung mit Eingaben, Beschlüssen und Terminen | Tool/Dok | {{ROLE_MANAGEMENT}} | {{MGMT_REVIEW_CYCLE}} |
| 18 | {{LINK:VA-21}} | Maßnahmenregister: Nichtkonformitäten, Ursachenanalyse, Wirksamkeitsbewertung | Tool | {{ROLE_ISB}} | laufend |
| 19 | {{LINK:R03}} | Erklärung zur Anwendbarkeit (SoA) mit Begründung, Herkunft und Umsetzungsstatus | Tool/Dok | {{ROLE_ISB}} | {{RISK_REVIEW_CYCLE}} |
| 20 | {{LINK:L00}} | Lesebestätigungen der Beschäftigten je freigegebener Richtlinienfassung | Tool | {{ROLE_ISB}} | {{POLICY_REVIEW_CYCLE}} |
> **Wizard-Hinweis:** Zeilen mit Quelle `Tool` werden nicht als Dokument erzeugt, sondern verlinken auf den Datensatz im {{TOOL_NAME}}. Bedingte Nachweise werden anhand der Feature-Flags ein-/ausgeblendet (z. B. Zeile 13 nur bei Flag `FLAG_CLOUD_USED` / `FLAG_AI_USED`, Zeile 10 nur bei Flag `FLAG_CRYPTO_PKI`).
## Verwandte Dokumente
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Informationssicherheitsleitlinie: {{LINK:L00}}
seed/isms-vorlagenpaket-v2/Statement-of-Applicability-ISO.md
+135
View File
@@ -0,0 +1,135 @@
# Erklaerung zur Anwendbarkeit (Statement of Applicability)
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Erklaerung zur Anwendbarkeit (Statement of Applicability) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## Zweck
Diese Erklaerung weist je Massnahme aus Anhang A der ISO/IEC 27001:2022 aus, ob sie anwendbar ist, warum sie einbezogen oder ausgeschlossen wurde, woraus sie sich ergibt und wie weit sie umgesetzt ist (ISO/IEC 27001:2022, 6.1.3 d). Sie wird bei jeder Risikobeurteilung ({{RISK_REVIEW_CYCLE}}) aktualisiert und von {{ROLE_MANAGEMENT}} freigegeben. Das Verfahren ist in {{LINK:R03}} geregelt.
**Spalten:** *Anwendbar* = ja/nein · *Begruendung* = Grund der Einbeziehung bzw. des Ausschlusses · *Herkunft* = Risiko-ID, gesetzliche oder vertragliche Anforderung · *Status* = umgesetzt / teilweise / geplant · *Nachweis* = Verweis in das Nachweisregister ({{LINK:NACHWEISREGISTER}}).
## A.5 Organisatorische Massnahmen (37 Massnahmen)
| Control | Titel | Anwendbar | Begruendung | Herkunft | Status | Richtlinie | Verfahren | Nachweis |
|---|---|:--:|---|---|---|---|---|---|
| A.5.1 | Informationssicherheitsrichtlinien | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:L00}} | - | |
| A.5.2 | Rollen und Verantwortlichkeiten | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | - | |
| A.5.3 | Aufgabentrennung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | - | |
| A.5.4 | Verantwortung der Leitung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | - | |
| A.5.5 | Kontakt mit Behörden | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | - | |
| A.5.6 | Kontakt mit speziellen Interessengruppen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | - | |
| A.5.7 | Bedrohungsinformationen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.5.8 | Informationssicherheit im Projektmanagement | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R01}} | VA-19 | |
| A.5.9 | Inventar der Informationen und Assets | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R02}} | VA-08 | |
| A.5.10 | Zulässige Nutzung von Informationen und Assets | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R02}} | VA-08 | |
| A.5.11 | Rückgabe von Assets | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R11}} | VA-08 | |
| A.5.12 | Klassifizierung von Informationen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R02}} | VA-08 | |
| A.5.13 | Kennzeichnung von Informationen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R02}} | VA-08 | |
| A.5.14 | Informationsübertragung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R09}} | - | |
| A.5.15 | Zugangssteuerung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.5.16 | Identitätsmanagement | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.5.17 | Authentisierungsinformationen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.5.18 | Zugriffsrechte | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.5.19 | Informationssicherheit in Lieferantenbeziehungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R13}} | VA-10 | |
| A.5.20 | Informationssicherheit in Lieferantenvereinbarungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R13}} | VA-10 | |
| A.5.21 | Informationssicherheit in der IKT-Lieferkette | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R13}} | VA-10 | |
| A.5.22 | Überwachung und Änderung von Lieferantenleistungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R13}} | VA-10 | |
| A.5.23 | Informationssicherheit bei Cloud-Diensten | {{#if FLAG_CLOUD_USED}}ja{{/if}}{{#unless FLAG_CLOUD_USED}}nein{{/unless}} | {{#if FLAG_CLOUD_USED}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_CLOUD_USED}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R12}} | VA-11 | |
| A.5.24 | Incident-Management: Planung und Vorbereitung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
| A.5.25 | Bewertung und Entscheidung zu Ereignissen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
| A.5.26 | Reaktion auf Informationssicherheitsvorfälle | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
| A.5.27 | Lernen aus Informationssicherheitsvorfällen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
| A.5.28 | Sammeln von Beweismaterial | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
| A.5.29 | Informationssicherheit während einer Störung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-02 | |
| A.5.30 | IKT-Bereitschaft für Business Continuity | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-02 | |
| A.5.31 | Rechtliche und vertragliche Anforderungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R14}} | VA-18 | |
| A.5.32 | Geistige Eigentumsrechte | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R14}} | VA-18 | |
| A.5.33 | Schutz von Aufzeichnungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R14}} | VA-18 | |
| A.5.34 | Datenschutz und Schutz von PII | {{#if FLAG_PERSONAL_DATA}}ja{{/if}}{{#unless FLAG_PERSONAL_DATA}}nein{{/unless}} | {{#if FLAG_PERSONAL_DATA}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_PERSONAL_DATA}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R14}} | VA-18 | |
| A.5.35 | Unabhängige Überprüfung der Informationssicherheit | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R03}} | VA-15 | |
| A.5.36 | Einhaltung von Richtlinien und Standards | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R03}} | VA-15 | |
| A.5.37 | Dokumentierte Betriebsabläufe | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
## A.6 Personenbezogene Massnahmen (8 Massnahmen)
| Control | Titel | Anwendbar | Begruendung | Herkunft | Status | Richtlinie | Verfahren | Nachweis |
|---|---|:--:|---|---|---|---|---|---|
| A.6.1 | Überprüfung (Screening) | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | VA-14 | |
| A.6.2 | Arbeitsvertragliche Regelungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | VA-14 | |
| A.6.3 | Awareness, Ausbildung und Schulung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | VA-12 | |
| A.6.4 | Disziplinarverfahren | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | - | |
| A.6.5 | Verantwortlichkeiten nach Beendigung oder Wechsel | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | VA-14 | |
| A.6.6 | Vertraulichkeitsvereinbarungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R05}} | VA-14 | |
| A.6.7 | Remote-Arbeit | {{#if FLAG_MOBILE_WORK}}ja{{/if}}{{#unless FLAG_MOBILE_WORK}}nein{{/unless}} | {{#if FLAG_MOBILE_WORK}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_MOBILE_WORK}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R06}} | - | |
| A.6.8 | Meldung von Informationssicherheitsereignissen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-01 | |
## A.7 Physische Massnahmen (14 Massnahmen)
| Control | Titel | Anwendbar | Begruendung | Herkunft | Status | Richtlinie | Verfahren | Nachweis |
|---|---|:--:|---|---|---|---|---|---|
| A.7.1 | Physische Sicherheitsperimeter | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.2 | Physische Zutrittssteuerung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.3 | Sicherung von Büros, Räumen und Einrichtungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.4 | Physische Überwachung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.5 | Schutz vor physischen und umweltbedingten Bedrohungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.6 | Arbeiten in Sicherheitsbereichen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.7 | Aufgeräumter Arbeitsplatz und Bildschirm | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.8 | Platzierung und Schutz von Betriebsmitteln | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.9 | Sicherheit von Assets außerhalb des Geländes | {{#if FLAG_MOBILE_DEVICES}}ja{{/if}}{{#unless FLAG_MOBILE_DEVICES}}nein{{/unless}} | {{#if FLAG_MOBILE_DEVICES}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_MOBILE_DEVICES}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R06}} | - | |
| A.7.10 | Speichermedien | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R06}} | VA-08 | |
| A.7.11 | Versorgungseinrichtungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.12 | Verkabelungssicherheit | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-17 | |
| A.7.13 | Wartung von Betriebsmitteln | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R07}} | VA-04 | |
| A.7.14 | Sichere Entsorgung oder Wiederverwendung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R11}} | VA-08 | |
## A.8 Technologische Massnahmen (34 Massnahmen)
| Control | Titel | Anwendbar | Begruendung | Herkunft | Status | Richtlinie | Verfahren | Nachweis |
|---|---|:--:|---|---|---|---|---|---|
| A.8.1 | Endgeräte der Benutzer | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R06}} | - | |
| A.8.2 | Privilegierte Zugriffsrechte | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.8.3 | Einschränkung des Informationszugriffs | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.8.4 | Zugriff auf Quellcode | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.5 | Sichere Authentisierung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.8.6 | Kapazitätssteuerung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.7 | Schutz vor Malware | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.8 | Management technischer Schwachstellen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-06 | |
| A.8.9 | Konfigurationsmanagement | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-04 | |
| A.8.10 | Löschung von Informationen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R11}} | VA-08 | |
| A.8.11 | Datenmaskierung | {{#if FLAG_PERSONAL_DATA}}ja{{/if}}{{#unless FLAG_PERSONAL_DATA}}nein{{/unless}} | {{#if FLAG_PERSONAL_DATA}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_PERSONAL_DATA}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R02}} | - | |
| A.8.12 | Verhinderung von Datenlecks | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.13 | Informationssicherung (Backup) | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-05 | |
| A.8.14 | Redundanz der Verarbeitungseinrichtungen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R04}} | VA-02 | |
| A.8.15 | Protokollierung (Logging) | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-13 | |
| A.8.16 | Überwachungsaktivitäten | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-13 | |
| A.8.17 | Uhrzeitsynchronisation | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-13 | |
| A.8.18 | Nutzung privilegierter Hilfsprogramme | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R08}} | VA-03 | |
| A.8.19 | Softwareinstallation auf Produktivsystemen | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R02}} | VA-04 | |
| A.8.20 | Netzwerksicherheit | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.21 | Sicherheit von Netzwerkdiensten | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R11}} | - | |
| A.8.22 | Netzwerksegmentierung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.23 | Web-Filterung | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | - | |
| A.8.24 | Nutzung von Kryptographie | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R09}} | VA-07 | |
| A.8.25 | Sicherer Entwicklungslebenszyklus | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.26 | Sicherheitsanforderungen an Anwendungen | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.27 | Sichere Systemarchitektur und -prinzipien | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.28 | Sichere Programmierung | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.29 | Sicherheitstests in Entwicklung und Abnahme | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.30 | Ausgelagerte Entwicklung | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.31 | Trennung von Entwicklungs-, Test- und Produktionsumgebungen | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R10}} | VA-16 | |
| A.8.32 | Änderungsmanagement | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-04 | |
| A.8.33 | Testinformationen | {{#if FLAG_DEV_INHOUSE}}ja{{/if}}{{#unless FLAG_DEV_INHOUSE}}nein{{/unless}} | {{#if FLAG_DEV_INHOUSE}}Aus der Risikobehandlung als erforderlich bestimmt.{{/if}}{{#unless FLAG_DEV_INHOUSE}}Nicht anwendbar - Begruendung eintragen.{{/unless}} | | | {{LINK:R11}} | VA-16 | |
| A.8.34 | Schutz von Systemen bei Audit-Tests | ja | Aus der Risikobehandlung als erforderlich bestimmt. | | | {{LINK:R10}} | VA-15 | |
## Managementsystem-Anforderungen (Kap. 4-10)
Die Anforderungen der Kapitel 4 bis 10 sind nicht Gegenstand der Anwendbarkeitserklaerung; sie gelten unmittelbar. Ihre Zuordnung zu den Richtlinien ist in `mapping-iso.json` gefuehrt.
seed/isms-vorlagenpaket-v2/Technische-Sicherheits-Baseline.md
+113
View File
@@ -0,0 +1,113 @@
# Technische Sicherheits-Baseline
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Vorgabedokument (Baseline) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## Zweck
Dieses Dokument legt die **konkreten technischen Mindestparameter** der Informationssicherheit fest. Es ist die zentrale Pflegestelle für alle messbaren Werte (Passwortlängen, Fristen, Verfahren). Die Richtlinien R01–R14 verweisen für exakte Werte auf die hier vergebenen **Baseline-IDs** (z. B. `BL-IAM-01`) und wiederholen die Kernaussage konkret im jeweiligen Umsetzungstext.
Änderungen an Parametern erfolgen ausschließlich hier und werden von {{ROLE_ISB}} freigegeben. Die Werte sind als anpassbare Defaults (Variablen) hinterlegt; sie entsprechen dem Stand der Technik (Orientierung u. a. an BSI IT-Grundschutz und aktuellen NIST-Empfehlungen).
## 1. Identitäts- und Zugriffsmanagement
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-IAM-01 | Passwortvorgaben | Mindestlänge {{PW_MIN_LENGTH}} Zeichen; {{PW_COMPLEXITY}}; Prüfung gegen bekannte/kompromittierte Passwörter; {{PW_ROTATION}} |
| BL-IAM-02 | Mehr-Faktor-Authentifizierung (MFA) | Verpflichtend für {{MFA_SCOPE}} |
| BL-IAM-03 | Sitzungsverwaltung | Automatische Sperre bei Inaktivität: {{SESSION_TIMEOUT}} |
| BL-IAM-04 | Kontosperrung | {{ACCOUNT_LOCKOUT}} |
| BL-IAM-05 | Rezertifizierung von Berechtigungen | {{RECERT_FREQ}}; privilegierte Rechte zusätzlich anlassbezogen |
| BL-IAM-06 | Privilegierte/technische Konten | Getrennte Verwaltung, Einzelzuordnung, verstärkte Protokollierung; Verwaltung über das zentrale Verzeichnis ({{TOOL_IAM}}) |
| BL-IAM-07 | Dokumentationsort IAM | Anträge/Freigaben/Sperrungen im {{TOOL_TICKET}}; Kontenverwaltung im zentralen Verzeichnis ({{TOOL_IAM}}) |
## 2. Kryptographie und Übertragung
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-CRY-01 | Transportverschlüsselung | Mindestens {{TLS_MIN}}; unsichere Protokolle deaktiviert |
| BL-CRY-02 | Zulässige Algorithmen/Schlüssellängen | {{CRYPTO_ALGO}} |
| BL-CRY-03 | Datenträgerverschlüsselung | Vollverschlüsselung mobiler Geräte und Datenträger (AES-256) |
| BL-CRY-04 | E-Mail-/Dateiaustausch | Verschlüsselung schutzbedürftiger Inhalte; sichere Austauschwege vorgegeben |
| BL-CRY-05 | Schlüsselverwaltung | Definierter Lebenszyklus (Erzeugung, Verteilung, Speicherung, Sperrung, Vernichtung){{#if FLAG_CRYPTO_PKI}}; PKI/Zertifikatsverwaltung etabliert{{/if}} |
## 3. Betriebssicherheit
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-OPS-01 | Patch-SLA | Kritisch: {{PATCH_SLA_CRIT}}; hoch: {{PATCH_SLA_HIGH}}; standard: {{PATCH_SLA_STD}} |
| BL-OPS-02 | Schwachstellen-Scanning | {{VULN_SCAN_FREQ}}; Nachverfolgung im {{TOOL_TICKET}} |
| BL-OPS-03 | Malware-Schutz | {{TECH_MALWARE}} auf allen Endpunkten/Servern; Signatur-/Engine-Update {{MALWARE_UPDATE}} |
| BL-OPS-04 | Protokollierung & Aufbewahrung | Zentrale Protokollierung ({{TECH_SIEM}}); Aufbewahrung {{LOG_RETENTION}}; manipulationsgeschützt |
| BL-OPS-05 | Datensicherung | Schema {{BACKUP_SCHEME}} über {{TECH_BACKUP}}; Aufbewahrung {{BACKUP_RETENTION}} |
| BL-OPS-06 | Wiederherstellungstests | {{BACKUP_TEST_FREQ}}; Ergebnis dokumentiert |
| BL-OPS-07 | Systemhärtung | Härtungsvorgaben (z. B. CIS-Benchmarks) für Standardsysteme |
| BL-OPS-08 | Technische Prüfung / Penetrationstest | {{PENTEST_FREQ}} bzw. risikoorientiert |
| BL-OPS-09 | Change-Management | Antrag/Bewertung/Test/Genehmigung/Doku im {{TOOL_TICKET}} |
{{#if FLAG_FW_ISO27001}}
| BL-OPS-10 | Zeitsynchronisation | Systemuhren aller protokollierenden Systeme auf {{NTP_SOURCES}} synchronisiert; Abweichungen werden überwacht |
| BL-OPS-11 | Kapazitätsmanagement | Überwachung der Auslastung (Rechenleistung, Speicher, Bandbreite, Lizenzen) {{CAPACITY_REVIEW_FREQ}}; Schwellenwerte lösen Meldung aus |
| BL-OPS-12 | Schutz vor Datenabfluss | Maßnahmen gegen unbefugten Abfluss schutzbedürftiger Informationen für {{DLP_SCOPE}} |
{{/if}}
## 4. Netzwerksicherheit
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-NET-01 | Segmentierung | Trennung nach Schutzbedarf; {{#if FLAG_OT_USED}}Produktions-/OT-Netze getrennt und besonders abgesichert; {{/if}}Gäste-/Fremdnetze isoliert |
| BL-NET-02 | Perimeter & Fernzugriff | Firewall mit Default-Deny; Fernzugriff nur über {{TECH_VPN}} mit MFA (BL-IAM-02) |
{{#if FLAG_FW_ISO27001}}
| BL-NET-03 | Web-Filterung | Zugriff auf externe Webinhalte gefiltert (Kategorien, bekannte Schadseiten); Ausnahmen dokumentiert und befristet |
{{/if}}
## 5. Endpoint und mobile Nutzung
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-EP-01 | Geräteverwaltung | Verwaltung über {{TECH_MDM}}; nur freigegebene Geräte |
| BL-EP-02 | Geräteverschlüsselung/Fernlöschung | Vollverschlüsselung (BL-CRY-03); Sperre/Löschung bei Verlust über {{TECH_MDM}} |
| BL-EP-03 | Wechseldatenträger | Nur verschlüsselt und freigegeben; Nutzung kontrolliert |
## 6. Physische Sicherheit
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-PHY-01 | Sicherheitszonen | Definierte Zonen; Zutritt bedarfsorientiert, dokumentiert, bei Wegfall entzogen |
| BL-PHY-02 | Zutrittsprotokollierung | Protokollierung zu schutzbedürftigen Bereichen; Besucher registriert und begleitet |
{{#if FLAG_FW_ISO27001}}
| BL-PHY-03 | Umgebungsschutz und Versorgung | Brandfrüherkennung, Schutz gegen Wasser, Temperatur-/Feuchteüberwachung in Technikräumen; unterbrechungsfreie Stromversorgung für kritische Systeme, regelmäßig geprüft |
| BL-PHY-04 | Aufgeräumter Arbeitsplatz und Bildschirmsperre | Schutzbedürftige Unterlagen/Datenträger bei Abwesenheit verschlossen; automatische Bildschirmsperre nach {{SESSION_TIMEOUT}} |
{{/if}}
## 7. Personal und Lieferanten
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-HR-01 | Awareness/Schulung | Bei Eintritt und danach mindestens {{REVIEW_CYCLE}}; Nachweis im {{TOOL_NAME}} |
| BL-SUP-01 | Lieferanten-Risikoklassen | Einstufung nach Schutzbedarf und Zugriff; Prüfung der Einhaltung (Nachweise/TISAX) |
| BL-DEL-01 | Sichere Löschung | Schutzbedarfsgerechtes Löschen/Vernichten (z. B. nach anerkannten Standards); Löschnachweis |
## 8. Governance und Projekte
| ID | Parameter | Vorgabe |
|----|-----------|---------|
| BL-GOV-01 | Audit-/Prüfzyklus | Interne Prüfung {{REVIEW_CYCLE}}; unabhängige Prüfung/Assessment mindestens alle 3 Jahre bzw. nach grundlegenden Änderungen |
| BL-PROJ-01 | Projekt-Klassifizierungskriterien | Dokumentierter Kriterienkatalog zur IS-Klassifizierung von Projekten (Auslöser/Schwellen für ISB-Einbindung) |
{{#if FLAG_FW_ISO27001}}
| BL-GOV-02 | Managementbewertung | Bewertung des ISMS durch die Leitung {{MGMT_REVIEW_CYCLE}} anhand fester Tagesordnung; Beschlüsse mit Verantwortlichem und Termin |
| BL-GOV-03 | Dokumentenlenkung | Prüfzyklus der Leitlinie/Richtlinien {{POLICY_REVIEW_CYCLE}}; Freigabe im Vier-Augen-Prinzip; Aufbewahrung abgelöster Fassungen {{RECORDS_RETENTION}} |
{{/if}}
## Änderungshistorie
| Version | Datum | Autor | Änderung |
|---------|-------|-------|----------|
| {{DOC_VERSION}} | {{DOC_DATE}} | {{ROLE_IT_LEAD}} | Erstellung |
seed/isms-vorlagenpaket-v2/_enrich.py
+168
View File
@@ -0,0 +1,168 @@
# -*- coding: utf-8 -*-
"""Ersetzt die Umsetzungstexte (IMPL) durch auditfeste, konkrete Fassungen mit
Baseline-Referenzen (BL-*), Werten (als Variablen) und Dokumentationsort.
Patcht die .md-Dateien und aktualisiert mapping.json. Fuegt {{LINK:BASELINE}} ein."""
import json, re, glob, os
BASE=os.path.dirname(__file__)
IMPL={
# R01
"1.2.1-M1":"Der ISMS-Geltungsbereich (Organisation, Standorte, Prozesse) ist im ISMS-Tool ({{TOOL_NAME}}) dokumentiert, versioniert und wird dort gepflegt; wesentliche Änderungen gibt {{ROLE_ISB}} frei.",
"1.2.1-M2":"Die {{ROLE_MANAGEMENT}} hat das ISMS per Managementbeschluss beauftragt, stellt Personal- und Budgetressourcen bereit und trägt die Gesamtverantwortung; die operative Steuerung liegt bei {{ROLE_ISB}}.",
"1.2.1-M3":"Die Wirksamkeit wird mindestens {{REVIEW_CYCLE}} in einer dokumentierten Managementbewertung anhand von Zielen, Kennzahlen sowie Audit- und Vorfallsergebnissen geprüft; Protokoll und Maßnahmen werden im ISMS-Tool ({{TOOL_NAME}}) abgelegt.",
"1.2.1-S1":"Messbare Informationssicherheitsziele und KPI (z. B. Schulungsquote, offene Maßnahmen, Patch-Compliance) sind definiert und werden im ISMS-Tool ({{TOOL_NAME}}) nachverfolgt.",
"1.2.2-M1":"Verantwortlichkeiten sind in der Rollen-/Verantwortungsmatrix (Abschnitt 5) und im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und den Rolleninhabern kommuniziert.",
"1.2.2-M2":"Die Rolle {{ROLE_ISB}} ist schriftlich benannt, mit Zeit-/Budgetressourcen und Weisungsrechten ausgestattet und berichtet direkt an die {{ROLE_MANAGEMENT}}.",
"1.2.2-S1":"In Konflikt stehende Tätigkeiten (Umsetzung vs. Kontrolle, Beantragung vs. Genehmigung) sind getrennt; unvermeidbare Doppelrollen werden dokumentiert und durch kompensierende Kontrollen (Vier-Augen-Prinzip) abgesichert.",
"1.2.2-S2":"Kontakte zu Behörden, CERT/CSIRT und relevanten Branchengremien werden von {{ROLE_ISB}} gepflegt und im ISMS-Tool hinterlegt.",
"1.2.3-M1":"Projekte werden zu Beginn anhand eines Kriterienkatalogs hinsichtlich Informationssicherheitsbedarf bewertet und klassifiziert; die Einstufung wird im {{TOOL_TICKET}} bzw. ISMS-Tool dokumentiert.",
"1.2.3-M2":"Bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} verbindlich eingebunden; ermittelte Sicherheitsanforderungen werden als Aufgaben im {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft.",
"1.2.3-S1":"Der Kriterienkatalog zur Projekteinstufung ist dokumentiert und wird einheitlich angewandt.",
# R02
"1.3.1-M1":"Informationswerte und Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst; Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.",
"1.3.1-M2":"Jedem Asset ist im Inventar ein verantwortlicher Owner zugeordnet, der Klassifizierung und Aktualität verantwortet.",
"1.3.1-S1":"Das Asset-Inventar wird laufend gepflegt und mindestens {{REVIEW_CYCLE}} vollständig auf Aktualität geprüft (Review durch {{ROLE_IT_LEAD}}).",
"1.3.2-M1":"Es gilt ein vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich); die Einstufung nach Vertraulichkeit, Integrität und Verfügbarkeit erfolgt durch den Asset Owner im ISMS-Tool.",
"1.3.2-M2":"Je Schutzklasse sind Handhabungsvorgaben zu Kennzeichnung, Speicherung, Übertragung (BL-CRY-01/04) und Löschung (BL-DEL-01) definiert und den Mitarbeitenden bekannt gemacht.",
"1.3.2-S1":"Bei wesentlichen Änderungen wird die Klassifizierung durch den Asset Owner überprüft und im ISMS-Tool aktualisiert.",
"1.3.3-M1":"Externe Hardware/IT-Komponenten werden vor Einsatz technisch und sicherheitsseitig bewertet und freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
"1.3.3-S1":"Der Anschluss nicht freigegebener Geräte wird soweit möglich technisch unterbunden (z. B. Portkontrolle, {{TECH_MDM}}).",
"1.3.4-M1":"Software wird vor Einsatz freigegeben; eine Liste zugelassener Software (Whitelist) wird im ISMS-Tool gepflegt, Beschaffung/Freigabe läuft über {{TOOL_TICKET}}.",
"1.3.4-S1":"Die Installation von Software ist für Standardnutzer technisch eingeschränkt (keine lokalen Adminrechte); Ausnahmen werden im {{TOOL_TICKET}} genehmigt.",
# R03
"1.4.1-M1":"Das Risikomanagement-Verfahren (Identifikation, Analyse, Bewertung, Behandlung) ist dokumentiert; Risiken werden im ISMS-Tool ({{TOOL_NAME}}) im Risikoregister geführt.",
"1.4.1-M2":"Je Risiko sind Eintrittswahrscheinlichkeit, Schadenshöhe, Behandlungsoption (reduzieren/vermeiden/übertragen/akzeptieren), Maßnahmen, Verantwortlicher und Termin hinterlegt.",
"1.4.1-M3":"Die Bewertung wird mindestens {{REVIEW_CYCLE}} und anlassbezogen (neue Systeme, Vorfälle, Änderungen) aktualisiert; Restrisiken werden von der {{ROLE_MANAGEMENT}} dokumentiert akzeptiert.",
"1.4.1-S1":"Bewertungsskalen und Akzeptanzschwellen sind definiert und im ISMS-Tool hinterlegt.",
"1.5.1-M1":"Die Einhaltung wird durch interne Audits und stichprobenartige Kontrollen (nach Auditplan) geprüft; Feststellungen werden im ISMS-Tool als Maßnahmen nachverfolgt.",
"1.5.1-S1":"Ein jährliches Auditprogramm mit Umfang, Turnus und Verantwortlichkeiten ist etabliert.",
"1.5.2-M1":"Das ISMS wird durch eine unabhängige Stelle (interne Revision oder externe Auditierung, z. B. TISAX) überprüft.",
"1.5.2-S1":"Die Ergebnisse werden in der Managementbewertung behandelt und fließen in den kontinuierlichen Verbesserungsprozess ein.",
# R04
"1.6.1-M1":"Sicherheitsereignisse können über einen definierten Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool sowie per E-Mail an {{ROLE_ISB}}) gemeldet werden.",
"1.6.1-M2":"Der Meldeweg ist allen Beschäftigten über Onboarding und Awareness (BL-HR-01) bekannt und niedrigschwellig, auch anonym, erreichbar.",
"1.6.1-S1":"Meldungen werden zentral im ISMS-Tool erfasst, kategorisiert und einem Schweregrad zugeordnet.",
"1.6.2-M1":"Ereignisse werden nach einem definierten Incident-Verfahren bewertet, priorisiert, eingedämmt, behoben und dokumentiert; die Bearbeitung erfolgt im {{TOOL_TICKET}}.",
"1.6.2-M2":"Verantwortlichkeiten und Eskalationsstufen sind definiert; {{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt technische Maßnahmen um.",
"1.6.2-S1":"Nach relevanten Vorfällen erfolgt eine Nachbereitung (Lessons Learned) mit Ableitung und Nachverfolgung von Verbesserungsmaßnahmen.",
"1.6.2-S2":"Vertragliche und gesetzliche Meldepflichten (Kunden/OEM, Aufsichtsbehörden, bei personenbezogenen Daten binnen 72 Stunden) sind im Verfahren berücksichtigt.",
"1.6.3-M1":"Ein Krisenmanagement mit Krisenstab, Rollen, Kommunikations- und Entscheidungswegen ist definiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.",
"1.6.3-S1":"Krisen- und Notfallpläne werden mindestens {{REVIEW_CYCLE}} geübt (z. B. Tabletop-Übung) und aktualisiert.",
"5.2.8-M1":"Für kritische IT-Dienste bestehen Wiederanlaufziele (RTO/RPO), Verantwortliche und Maßnahmen; {{ROLE_IT_LEAD}} verantwortet die Kontinuitätsplanung.",
"5.2.8-S1":"Wiederanlaufmaßnahmen werden mindestens {{BACKUP_TEST_FREQ}} getestet (BL-OPS-06); Ergebnisse werden dokumentiert.",
# R05
"2.1.1-M1":"Für sensible Tätigkeiten werden Qualifikation und Zuverlässigkeit im rechtlich zulässigen Rahmen sichergestellt (z. B. Qualifikationsnachweise, bei besonders schutzbedürftigen Rollen ggf. Führungszeugnis).",
"2.1.1-S1":"Sicherheitsanforderungen an Positionen sind in Stellenbeschreibungen hinterlegt; Überprüfungen erfolgen anlass- und rollenbezogen.",
"2.1.2-M1":"Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und Einhaltung der Informationssicherheit verpflichtet ({{ROLE_HR_LEAD}}); der Nachweis wird in der Personalakte geführt.",
"2.1.2-S1":"Die Vertraulichkeitsverpflichtung gilt nachvertraglich fort; Rückgabe von Assets und Entzug von Berechtigungen beim Austritt sind über {{TOOL_TICKET}} geregelt (Leaver-Prozess).",
"2.1.3-M1":"Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} geschult (BL-HR-01); Teilnahmenachweise werden im {{TOOL_NAME}} geführt.",
"2.1.3-S1":"Schulungen sind rollenspezifisch; die Wirksamkeit wird durch Phishing-Simulationen und gezielte Nachschulungen überprüft.",
# R06
"2.1.4-M1":"Mobiles Arbeiten ist in einer Regelung festgelegt; der Zugriff erfolgt ausschließlich über {{TECH_VPN}} mit MFA (BL-IAM-02) und freigegebene, verschlüsselte Geräte (BL-CRY-03).",
"2.1.4-M2":"Der Zugriff auf Unternehmensinformationen ist auf verwaltete Geräte ({{TECH_MDM}}) beschränkt; die Nutzung ist an die Einhaltung der Regelung gebunden.",
"2.1.4-S1":"Regeln zu Sichtschutz, Clean-Desk/Clean-Screen und zum Arbeiten in öffentlichen Umgebungen sind definiert und Teil der Awareness (BL-HR-01).",
"3.1.4-M1":"Mobile Geräte sind vollverschlüsselt (BL-CRY-03) und über {{TECH_MDM}} zentral verwaltet; Verlustmeldung erfolgt über den Meldeweg (R04) und {{TOOL_TICKET}}.",
"3.1.4-M2":"Bei Verlust können Geräte über {{TECH_MDM}} gesperrt und aus der Ferne gelöscht werden (BL-EP-02).",
"3.1.4-S1":"Der Einsatz privater Geräte (BYOD) ist geregelt bzw. untersagt; Wechseldatenträger werden nur verschlüsselt und freigegeben zugelassen (BL-EP-03).",
# R07
"3.1.1-M1":"Sicherheitszonen sind definiert (BL-PHY-01); der Zutritt zu schutzbedürftigen Bereichen (z. B. Serverraum) ist reglementiert und wird protokolliert (BL-PHY-02).",
"3.1.1-M2":"Zutrittsrechte werden bedarfsorientiert über {{TOOL_TICKET}} vergeben, dokumentiert und bei Wegfall (Austritt/Rollenwechsel) entzogen.",
"3.1.1-S1":"Besucher werden registriert und begleitet; technische Schutzmaßnahmen (Zutrittskontrolle, Alarm, Videoüberwachung im rechtlichen Rahmen) sind vorhanden.",
"3.1.3-M1":"Serverräume und Versorgungseinrichtungen (Strom, Klima, Verkabelung) sind zutrittsgeschützt und gegen Ausfall abgesichert.",
"3.1.3-S1":"Versorgungseinrichtungen werden gewartet und überwacht; für kritische Bereiche bestehen Redundanzen (z. B. USV, Klimaredundanz).",
# R08
"4.1.1-M1":"Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden eindeutig personenbezogen über {{TOOL_IAM}} vergeben; Sammelkonten werden vermieden bzw. dokumentiert und begründet.",
"4.1.1-S1":"Ausgabe, Rücknahme und Sperrung von Identifikationsmitteln werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).",
"4.1.2-M1":"Der Zugang ist durch sichere Authentifizierung geschützt; die Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden zentral über {{TOOL_IAM}} erzwungen.",
"4.1.2-M2":"Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA gemäß BL-IAM-02 über {{TECH_MFA}} durchgesetzt.",
"4.1.2-S1":"Sperrmechanismen (BL-IAM-04) und Sitzungs-Timeouts (BL-IAM-03) sind zentral konfiguriert.",
"4.1.3-M1":"Konten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen.",
"4.1.3-S1":"Privilegierte und technische Konten werden gesondert verwaltet, einzeln zugeordnet und verstärkt protokolliert (BL-IAM-06).",
"4.2.1-M1":"Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}.",
"4.2.1-M2":"Berechtigungen werden beim Wegfall entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05){{#if FLAG_CUSTOMER_SYSTEMS}}, auch für Zugriffe in Kundensystemen{{/if}}.",
"4.2.1-S1":"Berechtigungen werden rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Standardkonten erhalten keine privilegierten Rechte.",
# R09
"5.1.1-M1":"Zulässige Verfahren und Schlüssellängen nach BL-CRY-02 ({{CRYPTO_ALGO}}) sind vorgegeben; veraltete Verfahren sind untersagt.",
"5.1.1-M2":"Schlüssel werden über ihren Lebenszyklus (Erzeugung, Verteilung, Speicherung, Sperrung, Vernichtung) sicher verwaltet (BL-CRY-05).",
"5.1.1-S1":"Ein Kryptokonzept ist dokumentiert{{#if FLAG_CRYPTO_PKI}}; eine PKI/Zertifikatsverwaltung ist etabliert{{/if}}.",
"5.1.2-M1":"Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt: mindestens {{TLS_MIN}} (BL-CRY-01) und gesicherte Kanäle.",
"5.1.2-S1":"Regeln für E-Mail-Verschlüsselung und sichere Dateiübertragung sind definiert (BL-CRY-04).",
# R10
"5.2.1-M1":"Änderungen durchlaufen ein Change-Verfahren mit Antrag, Risikobewertung, Test, Genehmigung und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09).",
"5.2.2-M1":"Entwicklung, Test und Produktion sind getrennt betrieben.",
"5.2.2-S1":"Produktivdaten werden in Test-/Entwicklungsumgebungen nur anonymisiert/pseudonymisiert genutzt.",
"5.2.3-M1":"Malware-Schutz ist über {{TECH_MALWARE}} auf allen Endpunkten und Servern umgesetzt (BL-OPS-03).",
"5.2.3-S1":"Signaturen/Engines werden {{MALWARE_UPDATE}} aktualisiert; unnötige Netzwerkdienste sind deaktiviert.",
"5.2.4-M1":"Sicherheitsrelevante Ereignisse werden zentral über {{TECH_SIEM}} protokolliert und ausgewertet (BL-OPS-04).",
"5.2.4-S1":"Protokolle sind manipulationsgeschützt; die Aufbewahrung beträgt {{LOG_RETENTION}}.",
"5.2.5-M1":"Schwachstellen werden erfasst und nach BL-OPS-01 risikoorientiert gepatcht (kritisch {{PATCH_SLA_CRIT}}); die Nachverfolgung erfolgt im {{TOOL_TICKET}}.",
"5.2.5-S1":"Ein Schwachstellen-Scanning ({{VULN_SCAN_FREQ}}, BL-OPS-02) ist etabliert.",
"5.2.6-M1":"Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert technisch geprüft (Penetrationstest {{PENTEST_FREQ}}, BL-OPS-08).",
"5.2.7-M1":"Das Netzwerk ist nach Schutzbedarf segmentiert (BL-NET-01), zugangskontrolliert und nach außen über Firewall (Default-Deny, BL-NET-02) abgesichert.",
"5.2.7-M2":"Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert (BL-NET-01).",
"5.2.7-S1":"Ein aktueller Netzplan und ein Segmentierungskonzept werden gepflegt.",
"5.2.9-M1":"Daten und Dienste werden nach Schema {{BACKUP_SCHEME}} über {{TECH_BACKUP}} gesichert (BL-OPS-05); die Wiederherstellung ist geregelt.",
"5.2.9-M2":"Wiederherstellungstests werden mindestens {{BACKUP_TEST_FREQ}} durchgeführt und dokumentiert (BL-OPS-06).",
"5.2.9-S1":"Backups werden geschützt und ausgelagert aufbewahrt (offline/immutable), Aufbewahrung {{BACKUP_RETENTION}}.",
# R11
"5.3.1-M1":"Sicherheitsanforderungen sind fester Bestandteil von Beschaffungs- und Änderungsprozessen (Security by Design); die Prüfung erfolgt vor Freigabe im {{TOOL_TICKET}}.",
"5.3.1-M2":"Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews, automatisierten Sicherheitstests (SAST/Dependency-Scan) und dokumentierten Freigaben.",
"5.3.1-S1":"Sicherheitsanforderungen werden dokumentiert und ihre Umsetzung vor Produktivsetzung geprüft.",
"5.3.2-M1":"Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen definiert und vertraglich bzw. technisch vereinbart.",
"5.3.3-M1":"Rückgabe und sichere Löschung/Vernichtung (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt und werden nachgewiesen.",
"5.3.3-S1":"Löschverfahren richten sich nach dem Schutzbedarf; Löschungen werden dokumentiert (Löschprotokoll).",
# R12
"5.3.4-M1":"Bei geteilten externen Diensten wird eine wirksame Mandantentrennung gefordert und vertraglich zugesichert; die Prüfung erfolgt vor Freigabe.",
"5.3.4-M2":"Cloud-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
"5.3.4-S1":"Das Segregationskonzept des Anbieters wird dokumentiert und bei Änderungen aktualisiert.",
"5.3.4-KI-M1":"Der Einsatz von KI-/GenAI-Diensten ist geregelt; nur von {{ROLE_ISB}} freigegebene Dienste (Freigabeliste im ISMS-Tool) dürfen genutzt werden.",
"5.3.4-KI-M2":"Zulässige Datenklassen je KI-Dienst sind definiert; die Eingabe vertraulicher oder personenbezogener Daten in nicht freigegebene Dienste ist untersagt (Awareness BL-HR-01).",
"5.3.4-KI-M3":"Bei Freigabe wird geprüft und vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder an Dritte weitergegeben werden (Opt-out bzw. Enterprise-Vertrag).",
"5.3.4-KI-S1":"KI-Ergebnisse werden vor geschäftskritischer Verwendung durch Menschen geprüft (Human-in-the-Loop); der KI-Einsatz wird dokumentiert und regulatorische Anforderungen (EU AI Act) berücksichtigt.",
# R13
"6.1.1-M1":"Sicherheitsanforderungen an Lieferanten werden ermittelt, vertraglich vereinbart und überwacht; das Lieferantenverzeichnis wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
"6.1.1-M2":"Lieferanten werden risikoorientiert nach BL-SUP-01 (Schutzbedarf, Zugriff) klassifiziert.",
"6.1.1-S1":"Die Einhaltung wird risikobasiert überprüft (Selbstauskunft, Nachweise, Audits, TISAX-Label).",
"6.1.2-M1":"Vor dem Austausch schutzbedürftiger Informationen werden Vertraulichkeitsvereinbarungen (NDA) abgeschlossen und im ISMS-Tool hinterlegt.",
"6.1.2-S1":"Standardisierte NDA-Vorlagen mit Geltungsdauer sowie Rückgabe-/Löschpflichten werden verwendet.",
"6.1.3-M1":"Die Verantwortlichkeiten mit externen IT-Dienstleistern (Betriebs-, Sicherheits-, Melde- und Mitwirkungspflichten) sind abgegrenzt und vertraglich dokumentiert.",
"6.1.3-S1":"Schnittstellen sowie Eskalations- und Meldewege sind vertraglich vereinbart (Anbindung an R04).",
# R14
"7.1.1-M1":"Relevante gesetzliche, regulatorische und vertragliche Anforderungen werden in einem Compliance-/Rechtsregister im ISMS-Tool ({{TOOL_NAME}}) erfasst und ihre Einhaltung nachverfolgt.",
"7.1.1-S1":"Das Register wird mindestens {{REVIEW_CYCLE}} aktualisiert; je Anforderung ist ein Verantwortlicher benannt.",
"7.1.2-M1":"Datenschutzrechtliche Anforderungen (DSGVO) werden berücksichtigt; {{ROLE_DPO}} ist eingebunden und bei relevanten Vorhaben (Datenschutz-Folgenabschätzung) beteiligt.",
"7.1.2-M2":"Das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt und gepflegt.",
"7.1.2-S1":"Technische und organisatorische Maßnahmen (TOM), Löschkonzepte (BL-DEL-01) und Prozesse für Betroffenenrechte sind geregelt.",
}
def clean(s):
s=re.sub(r"\{\{#if \w+\}\}","",s); s=re.sub(r"\{\{/if\}\}","",s)
s=re.sub(r"\s+"," ",s).strip().replace(" .",".").replace(" ,",",")
return s
# --- Patch .md-Dateien: Zeile nach <!-- IMPL id --> ersetzen ---
patched=0
for fp in glob.glob(os.path.join(BASE,"richtlinien/*.md")):
lines=open(fp,encoding="utf-8").read().split("\n")
out=[]; i=0
while i<len(lines):
out.append(lines[i])
m=re.match(r"<!-- IMPL ([0-9.\-A-Za-z]+) -->\s*$", lines[i])
if m and m.group(1) in IMPL and i+1<len(lines):
out.append(IMPL[m.group(1)]); i+=2; patched+=1; continue
i+=1
# {{LINK:BASELINE}} in "Verwandte Dokumente" ergaenzen
txt="\n".join(out)
if "{{LINK:BASELINE}}" not in txt:
txt=txt.replace("- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}",
"- Technische Sicherheits-Baseline: {{LINK:BASELINE}}\n- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}")
open(fp,"w",encoding="utf-8").write(txt)
# --- mapping.json aktualisieren ---
d=json.load(open(os.path.join(BASE,"mapping.json"),encoding="utf-8"))
upd=0
for a in d["anforderungen"]:
if a["id"] in IMPL:
a["implementation"]=clean(IMPL[a["id"]]); upd+=1
json.dump(d,open(os.path.join(BASE,"mapping.json"),"w",encoding="utf-8"),ensure_ascii=False,indent=1)
print("IMPL-Bloecke gepatcht:",patched,"| mapping aktualisiert:",upd,"| Overrides:",len(IMPL))
seed/isms-vorlagenpaket-v2/_fix.py
+21
View File
@@ -0,0 +1,21 @@
# -*- coding: utf-8 -*-
import json, re, os
BASE=os.path.dirname(__file__)
mp=os.path.join(BASE,"mapping.json")
d=json.load(open(mp,encoding="utf-8"))
def clean(s):
# entferne Handlebars-Conditional-Wrapper, behalte Innentext
s=re.sub(r"\{\{#if \w+\}\}","",s)
s=re.sub(r"\{\{/if\}\}","",s)
s=re.sub(r"\s+"," ",s).strip()
s=s.replace(" .",".").replace(" ,",",")
return s
for a in d["anforderungen"]:
a["requirement"]=clean(a["requirement"])
a["implementation"]=clean(a["implementation"])
if a["policy"]=="L00":
a["impl_anchor"]=a["req_anchor"] # Leitlinie: kombiniert
json.dump(d,open(mp,"w",encoding="utf-8"),ensure_ascii=False,indent=1)
print("mapping bereinigt:",len(d["anforderungen"]),"Eintraege")
seed/isms-vorlagenpaket-v2/_generate_iso.py
+525
View File
@@ -0,0 +1,525 @@
# -*- coding: utf-8 -*-
"""
Legt das ISO/IEC-27001:2022-Mapping auf die bestehende Dokumentenbibliothek (Variante A).
Prinzip: EIN Dokumentensatz, ZWEI Framework-Mappings.
* Die vorhandenen Abschnitte (VDA-ISA-Controls) bleiben unveraendert; ihr
Umsetzungstext gilt fuer beide Normen.
* Je Abschnitt kommt ein ISO-Anforderungsblock hinzu, der ueber
{{#if FLAG_FW_ISO27001}} nur fuer ISO-Mandanten sichtbar ist. Der bestehende
VDA-ISA-Block wird spiegelbildlich in {{#if FLAG_FW_TISAX}} gefasst.
* Wo die Bibliothek keinen passenden Abschnitt hat (Managementsystem-Klauseln,
einzelne Annex-A-Controls), werden neue ISO-only-Abschnitte erzeugt — im
gleichen Aufbau und ausschliesslich mit Platzhaltern individualisiert.
Idempotent: erzeugte Bloecke sind durch Sentinels begrenzt und werden bei jedem
Lauf zuerst entfernt. Aufruf: python3 _generate_iso.py [--check]
Ergebnis:
* richtlinien/*.md — ISO-Bloecke + neue ISO-Abschnitte
* verfahren/*.md — FULFILLS-Header um ISO-Anforderungs-IDs ergaenzt
* mapping-iso.json — 120 Anforderungen im Importer-Kontraktformat
* Statement-of-Applicability-ISO.md — SoA-Geruest mit den Pflichtangaben aus 6.1.3 d)
"""
import json, os, re, sys, glob, collections
BASE = os.path.dirname(os.path.abspath(__file__))
CHECK = "--check" in sys.argv
LANG = sys.argv[sys.argv.index("--lang") + 1] if "--lang" in sys.argv else "de"
# Sprachabhaengige Marker und Beschriftungen. Struktur (Zuordnung, Bedingungen, Verfahren)
# kommt immer aus _iso_crosswalk.json im deutschen Verzeichnis; nur Texte sind uebersetzt.
LANGS = {
"de": {"dir": BASE, "sections": "_iso_sections.json", "texts": None,
"req": "**Anforderung**", "impl": "**Umsetzung bei", "impl_head": "**Umsetzung bei {{ORG_NAME}}**",
"anchor4": r"^## 4\. Verbindlichkeit", "appendix": "## Anhang A — %s",
"ref_label": "*Anforderungsbezug:*", "isa_name": "VDA ISA", "iso_name": "ISO/IEC 27001",
"no_annex": "ohne Anhang-A-Bezug (eigene Ergaenzung)",
"lbl_tis": "*Anforderungen nach VDA ISA 2027:*", "lbl_iso": "*Anforderungen nach ISO/IEC 27001:*",
"soa": "Statement-of-Applicability-ISO.md",
"soa_strings": {
"title": "Erklaerung zur Anwendbarkeit (Statement of Applicability)",
"head": {"k": "Dokumenteninformation", "v": "Wert", "type": "Dokumententyp", "scope": "Geltungsbereich",
"org": "Organisation", "resp": "Verantwortlich", "appr": "Freigabe durch",
"ver": "Version", "date": "Datum", "status": "Status"},
"purpose_head": "Zweck",
"purpose": "Diese Erklaerung weist je Massnahme aus Anhang A der ISO/IEC 27001:2022 aus, ob sie anwendbar "
"ist, warum sie einbezogen oder ausgeschlossen wurde, woraus sie sich ergibt und wie weit sie "
"umgesetzt ist (ISO/IEC 27001:2022, 6.1.3 d). Sie wird bei jeder Risikobeurteilung "
"({{RISK_REVIEW_CYCLE}}) aktualisiert und von {{ROLE_MANAGEMENT}} freigegeben. Das Verfahren "
"ist in {{LINK:R03}} geregelt.",
"columns": "**Spalten:** *Anwendbar* = ja/nein · *Begruendung* = Grund der Einbeziehung bzw. des "
"Ausschlusses · *Herkunft* = Risiko-ID, gesetzliche oder vertragliche Anforderung · *Status* = "
"umgesetzt / teilweise / geplant · *Nachweis* = Verweis in das Nachweisregister "
"({{LINK:NACHWEISREGISTER}}).",
"themen": [("A.5", "Organisatorische Massnahmen"), ("A.6", "Personenbezogene Massnahmen"),
("A.7", "Physische Massnahmen"), ("A.8", "Technologische Massnahmen")],
"measures": "Massnahmen",
"cols": ["Control", "Titel", "Anwendbar", "Begruendung", "Herkunft", "Status", "Richtlinie", "Verfahren", "Nachweis"],
"incl": "Aus der Risikobehandlung als erforderlich bestimmt.",
"excl": "Nicht anwendbar - Begruendung eintragen.",
"yes": "ja", "no": "nein",
"clauses_head": "Managementsystem-Anforderungen (Kap. 4-10)",
"clauses": "Die Anforderungen der Kapitel 4 bis 10 sind nicht Gegenstand der Anwendbarkeitserklaerung; "
"sie gelten unmittelbar. Ihre Zuordnung zu den Richtlinien ist in `mapping-iso.json` gefuehrt.",
},},
"en": {"dir": os.path.normpath(os.path.join(BASE, "..", "isms-vorlagenpaket-v2-en")),
"sections": "_iso_sections_en.json", "texts": "_iso_texts_en.json",
"req": "**Requirement**", "impl": "**Implementation at", "impl_head": "**Implementation at {{ORG_NAME}}**",
"anchor4": r"^## 4\. Binding nature", "appendix": "## Annex A — %s",
"ref_label": "*Requirement reference:*", "isa_name": "VDA ISA", "iso_name": "ISO/IEC 27001",
"no_annex": "no Annex A reference (own addition)",
"lbl_tis": "*Requirements per VDA ISA 2027:*", "lbl_iso": "*Requirements per ISO/IEC 27001:*",
"soa": "Statement-of-Applicability-ISO.md",
"soa_strings": {
"title": "Statement of Applicability",
"head": {"k": "Document information", "v": "Value", "type": "Document type", "scope": "Scope",
"org": "Organisation", "resp": "Responsible", "appr": "Approved by",
"ver": "Version", "date": "Date", "status": "Status"},
"purpose_head": "Purpose",
"purpose": "For each control of Annex A of ISO/IEC 27001:2022 this statement records whether it is "
"applicable, why it was included or excluded, what it derives from and how far it is "
"implemented (ISO/IEC 27001:2022, 6.1.3 d). It is updated with every risk assessment "
"({{RISK_REVIEW_CYCLE}}) and approved by {{ROLE_MANAGEMENT}}. The procedure is set out in "
"{{LINK:R03}}.",
"columns": "**Columns:** *Applicable* = yes/no · *Justification* = reason for inclusion or exclusion · "
"*Origin* = risk ID, legal or contractual requirement · *Status* = implemented / partial / "
"planned · *Evidence* = reference into the evidence register ({{LINK:NACHWEISREGISTER}}).",
"themen": [("A.5", "Organisational controls"), ("A.6", "People controls"),
("A.7", "Physical controls"), ("A.8", "Technological controls")],
"measures": "controls",
"cols": ["Control", "Title", "Applicable", "Justification", "Origin", "Status", "Policy", "Procedure", "Evidence"],
"incl": "Determined as necessary by the risk treatment.",
"excl": "Not applicable - enter justification.",
"yes": "yes", "no": "no",
"clauses_head": "Management system requirements (clauses 4-10)",
"clauses": "The requirements of clauses 4 to 10 are not subject to the Statement of Applicability; they "
"apply directly. Their allocation to the policies is held in `mapping-iso.json`.",
},},
}
if LANG not in LANGS:
sys.exit("Unbekannte Sprache: %s (erlaubt: de, en)" % LANG)
L = LANGS[LANG]
OUT = L["dir"]
S_TIS_A, S_TIS_E = "<!-- FW:TISAX-REQ-START -->", "<!-- FW:TISAX-REQ-END -->"
S_ISO_A, S_ISO_E = "<!-- FW:ISO-REQ-START -->", "<!-- FW:ISO-REQ-END -->"
S_SEC_A, S_SEC_E = "<!-- FW:ISO-SECTION-START -->", "<!-- FW:ISO-SECTION-END -->"
S_REF_E = "<!-- FW:REF-END -->"
# Zwischenueberschriften, die NUR im Parallelbetrieb (beide Frameworks aktiv) erscheinen.
LBL_TIS = "{{#if FLAG_FW_ISO27001}}%s{{/if}}" % L["lbl_tis"]
LBL_ISO = "{{#if FLAG_FW_TISAX}}%s{{/if}}" % L["lbl_iso"]
# ── Neue ISO-only-Abschnitte: Titel + Umsetzungstext ──────────────────────
# Redaktionell gepflegt in _iso_sections.json (Reihenfolge = Reihenfolge im Dokument).
_sec = json.load(open(os.path.join(BASE, L["sections"]), encoding="utf-8"))["abschnitte"]
NEW_SECTIONS = collections.OrderedDict((k, (v["titel"], v["umsetzung"])) for k, v in _sec.items())
def strip_generated(text):
"""Erzeugte Bloecke entfernen — macht den Lauf idempotent."""
# ISO-Abschnitte
text = re.sub(re.escape(S_SEC_A) + r".*?" + re.escape(S_SEC_E) + r"\n?", "", text, flags=re.S)
# ISO-Anforderungsbloecke
text = re.sub(re.escape(S_ISO_A) + r".*?" + re.escape(S_ISO_E) + r"\n?", "", text, flags=re.S)
# TISAX-Klammer zurueckbauen (Inhalt behalten)
def unwrap(m):
lines = m.group(1).split("\n")
if lines and lines[0] == "{{#if FLAG_FW_TISAX}}": lines.pop(0)
if lines and lines[0] == LBL_TIS: lines.pop(0) # Label nur im Parallelbetrieb, sprachabhaengig
if lines and lines[0] == "": lines.pop(0)
while lines and lines[-1] == "": lines.pop()
if lines and lines[-1] == "{{/if}}": lines.pop()
return "\n".join(lines) + "\n"
text = re.sub(re.escape(S_TIS_A) + r"\n(.*?)" + re.escape(S_TIS_E) + r"\n", unwrap, text, flags=re.S)
# Referenzzeile entfernen und die urspruengliche Ueberschriften-Klammer wiederherstellen.
# Der Start-Sentinel traegt das Original mit, damit der Rueckbau exakt ist.
# Rueckwaertskompatibel: fruehere Fassung trug den Bezug noch in der Ueberschrift.
text = re.sub(r"^(### .*?) \{\{#if FLAG_FW_TISAX\}\}(\(ISA [^)]*\))\{\{/if\}\}.*$",
r"\1 \2", text, flags=re.M)
lines = text.split("\n")
out, last_head = [], None
i = 0
while i < len(lines):
ln = lines[i]
m = re.match(r"^<!-- FW:REF-START ORIG:(.*?) -->$", ln)
if m:
if last_head is not None:
out[last_head] = out[last_head] + " " + m.group(1)
while i < len(lines) and lines[i] != S_REF_E:
i += 1
i += 1 # S_REF_E ueberspringen
if i < len(lines) and lines[i] == "":
i += 1 # nachfolgende Leerzeile ebenfalls
continue
if ln.startswith("### "):
last_head = len(out)
out.append(ln)
i += 1
return "\n".join(out)
def iso_bullets(entries):
out = []
for e in sorted(entries, key=lambda x: x["_sort"]):
out.append("<!-- REQ %s -->" % e["id"])
out.append("- **[ISO %s]** %s" % (e["ref"], e["requirement"]))
return out
def main():
cw = json.load(open(os.path.join(BASE, "_iso_crosswalk.json"), encoding="utf-8"))["zuordnung"]
# Struktur ist sprachneutral; Titel und Anforderungstext kommen bei anderen Sprachen
# aus der jeweiligen Textdatei.
if L["texts"]:
tx = json.load(open(os.path.join(BASE, L["texts"]), encoding="utf-8"))["texte"]
fehlend = [e["ref"] for e in cw if e["ref"] not in tx]
if fehlend:
sys.exit("Uebersetzung fehlt fuer: %s" % ", ".join(fehlend[:5]))
for e in cw:
e["title"] = tx[e["ref"]]["title"]
e["requirement"] = tx[e["ref"]]["requirement"]
for e in cw:
parts = re.split(r"[.\-]", e["ref"].replace("A.", ""))
e["_sort"] = (0 if e["kind"] == "clause" else 1, [int(p) if p.isdigit() else 0 for p in parts])
by_section = collections.defaultdict(list) # (policy, section) -> entries
for e in cw:
by_section[(e["policy"], e["section"])].append(e)
changed = []
# ── 1. Richtlinien patchen ────────────────────────────────────────────────
for path in sorted(glob.glob(os.path.join(OUT, "richtlinien", "*.md"))):
code = os.path.basename(path).split("_")[0]
raw = open(path, encoding="utf-8").read()
new = strip_generated(raw)
if code == "L00":
new = patch_l00(new, by_section.get(("L00", "ISO-LEITLINIE"), []))
else:
new = patch_policy(new, code, by_section)
if new != raw:
changed.append(os.path.basename(path))
if not CHECK:
open(path, "w", encoding="utf-8").write(new)
# ── 2. FULFILLS-Header der Verfahren um ISO-IDs ergaenzen ─────────────────
va_ids = collections.defaultdict(list)
for e in cw:
for va in e["verfahren"]:
va_ids[va].append(e)
for path in sorted(glob.glob(os.path.join(OUT, "verfahren", "*.md"))):
va = os.path.basename(path).split("_")[0]
raw = open(path, encoding="utf-8").read()
m = re.search(r"<!--\s*FULFILLS\s+([^|]+?)\s*\|\s*POLICY\s+(\S+)\s*-->", raw)
if not m:
continue
existing = [x.strip() for x in m.group(1).split(",") if x.strip()]
base_ids = [x for x in existing if not (x.startswith("A.") or re.match(r"^\d+(\.\d+)*-1$", x))]
iso_new = sorted({e["id"] for e in va_ids.get(va, [])}, key=lambda s: (s.startswith("A."), s))
merged = base_ids + iso_new
header = "<!-- FULFILLS %s | POLICY %s -->" % (", ".join(merged), m.group(2))
new = raw[:m.start()] + header + raw[m.end():]
if new != raw:
changed.append(os.path.basename(path))
if not CHECK:
open(path, "w", encoding="utf-8").write(new)
# ── 3. mapping-iso.json schreiben ─────────────────────────────────────────
anforderungen = []
for e in sorted(cw, key=lambda x: x["_sort"]):
impl = "IMPL " + e["section"]
anforderungen.append(collections.OrderedDict([
("id", e["id"]), ("policy", e["policy"]), ("control", e["ref"]),
("kind", e["kind"]), ("title", e["title"]), ("type", "MUSS"),
("soa_relevant", e["soa_relevant"]), ("applicable", True),
("condition", e["condition"]),
("req_anchor", "REQ " + e["id"]), ("impl_anchor", impl),
("requirement", e["requirement"]),
("link", "{{LINK:%s#%s}}" % (e["policy"], e["section"])),
("nachweis_link", "{{LINK:NACHWEISREGISTER}}"),
("verfahren", e["verfahren"]),
]))
mapping = collections.OrderedDict([
("meta", collections.OrderedDict([
("paket", "ISMS-Vorlagenpaket v2 — Framework-Mapping ISO/IEC 27001:2022"),
("standard", "ISO/IEC 27001:2022 (Kap. 4-10 + Anhang A)"),
("framework", "ISO_27001"),
("version", "2.1"),
("bibliothek", "gemeinsam mit dem VDA-ISA-Mapping (mapping.json) — ein Dokumentensatz, zwei Mappings"),
("hinweis", "Anforderungstexte sind eigene Paraphrasen (keine woertlichen Normzitate); "
"die Referenzen sind exakt zum Nachschlagen. Der Umsetzungstext wird ueber impl_anchor "
"aus dem jeweiligen Richtlinienabschnitt aufgeloest und ist mit dem VDA-ISA-Mapping geteilt."),
("coverage", "27 Klausel-Anforderungen (Kap. 4-10) + 93 Anhang-A-Controls = 120 Eintraege"),
])),
("anforderungen", anforderungen),
])
if not CHECK:
with open(os.path.join(OUT, "mapping-iso.json"), "w", encoding="utf-8") as fh:
json.dump(mapping, fh, ensure_ascii=False, indent=1)
fh.write("\n")
# ── 4. SoA-Geruest schreiben (Pflichtangaben nach 6.1.3 d) ───────────────
SOA = L["soa_strings"]
THEMEN = SOA["themen"]
head = SOA["head"]
lines = [
"# " + SOA["title"], "",
"| %s | %s |" % (head["k"], head["v"]),
"|-----------------------|------|",
"| %s | %s |" % (head["type"], SOA["title"]),
"| %s | {{ISMS_SCOPE}} |" % head["scope"],
"| %s | {{ORG_NAME}} |" % head["org"],
"| %s | {{ROLE_ISB}} |" % head["resp"],
"| %s | {{ROLE_MANAGEMENT}} |" % head["appr"],
"| %s | {{DOC_VERSION}} |" % head["ver"],
"| %s | {{DOC_DATE}} |" % head["date"],
"| %s | {{DOC_STATUS}} |" % head["status"],
"", "## " + SOA["purpose_head"], "", SOA["purpose"], "", SOA["columns"], "",
]
ctl = [e for e in sorted(cw, key=lambda x: x["_sort"]) if e["kind"] != "clause"]
for pref, titel in THEMEN:
rows = [e for e in ctl if e["ref"].startswith(pref + ".")]
lines += ["## %s %s (%d %s)" % (pref, titel, len(rows), SOA["measures"]), "",
"| " + " | ".join(SOA["cols"]) + " |",
"|---|---|:--:|---|---|---|---|---|---|"]
for e in rows:
va = ", ".join(e["verfahren"]) if e["verfahren"] else "-"
if e["condition"]:
begr = ("{{#if %s}}%s{{/if}}{{#unless %s}}%s{{/unless}}"
% (e["condition"], SOA["incl"], e["condition"], SOA["excl"]))
anw = "{{#if %s}}%s{{/if}}{{#unless %s}}%s{{/unless}}" % (
e["condition"], SOA["yes"], e["condition"], SOA["no"])
else:
begr, anw = SOA["incl"], SOA["yes"]
lines.append("| %s | %s | %s | %s | | | {{LINK:%s}} | %s | |" %
(e["ref"], e["title"], anw, begr, e["policy"], va))
lines.append("")
lines += ["## " + SOA["clauses_head"], "", SOA["clauses"], ""]
if not CHECK:
open(os.path.join(OUT, L["soa"]), "w", encoding="utf-8").write("\n".join(lines))
# ── 5. Control-Titel fuer die Oberflaeche erzeugen (B3) ───────────────────
# Eigene Map: ISA und ISO kollidieren bei 6.1.1-6.1.3 (Lieferanten vs. Risikoklauseln).
ts = ["// AUTOGENERIERT von seed/isms-vorlagenpaket-v2/_generate_iso.py — nicht von Hand aendern.",
"// Quelle: mapping-iso.json. Neu erzeugen: python3 seed/isms-vorlagenpaket-v2/_generate_iso.py",
"//",
"// Eigene Map statt Ergaenzung von CONTROL_TITLES: die Schluessel 6.1.1-6.1.3 sind in",
"// beiden Katalogen belegt (VDA ISA: Lieferanten - ISO: Risikobeurteilung/-behandlung).",
"",
"export const CONTROL_TITLES_ISO: Record<string, string> = {"]
for e in sorted(cw, key=lambda x: x["_sort"]):
ts.append(' "%s": "%s",' % (e["ref"], e["title"].replace('"', '\\"')))
ts += ["};", "",
"/** Titel einer ISO/IEC-27001-Anforderung; Fallback: „ISO <ref>“. */",
"export function controlTitleIso(ref: string): string {",
" return CONTROL_TITLES_ISO[ref] ?? `ISO ${ref}`;",
"}", ""]
out_ts = os.path.join(BASE, "..", "..", "src", "lib", "control-titles-iso.ts")
if not CHECK and LANG == "de":
with open(os.path.normpath(out_ts), "w", encoding="utf-8") as fh:
fh.write("\n".join(ts))
# ── 6. ISO -> VDA-ISA-Crosswalk fuer die Oberflaeche (B2) ────────────────
# Erlaubt es, die vorhandenen C6-Umsetzungshinweise (nach ISA-Control verschluesselt)
# auch fuer ISO-Anforderungen anzuzeigen, ohne den Hinweiskatalog zu duplizieren.
pairs = [(e["ref"], e["section"]) for e in sorted(cw, key=lambda x: x["_sort"])
if not e["section"].startswith("ISO-")]
only = [e["ref"] for e in sorted(cw, key=lambda x: x["_sort"]) if e["section"].startswith("ISO-")]
cx = ["// AUTOGENERIERT von seed/isms-vorlagenpaket-v2/_generate_iso.py — nicht von Hand aendern.",
"// Quelle: _iso_crosswalk.json. Neu erzeugen: python3 seed/isms-vorlagenpaket-v2/_generate_iso.py",
"//",
"// Zuordnung ISO-Anforderung -> VDA-ISA-Control desselben Bibliotheksabschnitts.",
"// Zweck: die vorhandenen Umsetzungshinweise (ImplementationHint, nach ISA-Control",
"// verschluesselt) fuer ISO-Anforderungen wiederverwenden, statt sie zu duplizieren.",
"// ISO-Anforderungen ohne Eintrag liegen in einem ISO-eigenen Abschnitt — fuer sie",
"// gibt es (noch) keine Hinweise.",
"",
"export const ISO_TO_ISA: Record<string, string> = {"]
for ref, sec in pairs:
cx.append(' "%s": "%s",' % (ref, sec))
cx += ["};", "",
"/** ISO-Anforderungen, die in einem ISO-eigenen Abschnitt liegen (kein ISA-Gegenstueck). */",
"export const ISO_ONLY: readonly string[] = [",
" " + ", ".join('"%s"' % r for r in only) + ",",
"];", "",
"/** ISA-Control, dessen Umsetzungshinweise fuer diese ISO-Anforderung gelten (oder null). */",
"export function isaControlForIso(ref: string): string | null {",
" return ISO_TO_ISA[ref] ?? null;",
"}", ""]
out_cx = os.path.normpath(os.path.join(BASE, "..", "..", "src", "lib", "iso-isa-crosswalk.ts"))
if not CHECK and LANG == "de":
with open(out_cx, "w", encoding="utf-8") as fh:
fh.write("\n".join(cx))
# ── 7. Control-Specs fuer die ISO-Bewertung (Belegbasis, B1) ─────────────
# Framework-neutrale Belegspezifikation je ISO-Control: zustaendige Richtlinie/
# Verfahren aus dem Mapping; needsAsset/needsRisk via ISO_TO_ISA vom ISA-Spec
# (seed/scoping/c5-controls.json) geerbt, fuer die ISO-eigenen Abschnitte explizit.
c5 = json.load(open(os.path.normpath(os.path.join(BASE, "..", "scoping", "c5-controls.json")), encoding="utf-8"))
c5_by = {c["control"]: c for c in c5}
ASSET_OVERRIDE = {"A.5.9"}
RISK_OVERRIDE = {"6.1.2", "6.1.3", "8.2", "8.3"}
sp = ["// AUTOGENERIERT von seed/isms-vorlagenpaket-v2/_generate_iso.py — nicht von Hand aendern.",
"// Quelle: mapping-iso.json + seed/scoping/c5-controls.json. Neu erzeugen: python3 seed/isms-vorlagenpaket-v2/_generate_iso.py",
"//",
"// Belegspezifikation je ISO-Control (Feindesign §1/§2, B1): welche Richtlinie/Verfahren",
"// zustaendig sind und ob Asset-/Risiko-Verknuepfung gefordert ist. needsAsset/needsRisk",
"// werden ueber ISO_TO_ISA vom ISA-Spec geerbt; ISO-eigene Abschnitte explizit gesetzt.",
"// Strukturgleich zu ControlSpec (src/lib/maturity.ts) — von der GETEILTEN Belegbasis konsumiert.",
"",
"export interface IsoControlSpec {",
" control: string;",
" title: string;",
" policy: string[];",
" verfahren: string[];",
" needsAsset: boolean;",
" needsRisk: boolean;",
"}",
"",
"const SPECS: Record<string, IsoControlSpec> = {"]
for e in sorted(cw, key=lambda x: x["_sort"]):
ref = e["ref"]; sec = e["section"]
if sec.startswith("ISO-"):
na = nr = False
else:
base = c5_by.get(sec)
na = bool(base["needsAsset"]) if base else False
nr = bool(base["needsRisk"]) if base else False
if ref in ASSET_OVERRIDE: na = True
if ref in RISK_OVERRIDE: nr = True
pol = '["%s"]' % e["policy"] if e["policy"] else "[]"
vf = "[" + ", ".join('"%s"' % v for v in e["verfahren"]) + "]"
sp.append(' "%s": { control: "%s", title: "%s", policy: %s, verfahren: %s, needsAsset: %s, needsRisk: %s },'
% (ref, ref, e["title"].replace('"', '\\"'), pol, vf, str(na).lower(), str(nr).lower()))
sp += ["};", "",
"/** Belegspezifikation eines ISO-Controls; Fallback fuer unbekannte Controls. */",
"export function controlSpecIso(control: string): IsoControlSpec {",
" return SPECS[control] ?? { control, title: `ISO ${control}`, policy: [], verfahren: [], needsAsset: false, needsRisk: false };",
"}",
"",
"/** Alle ISO-Controls mit Belegspezifikation (Klauseln 4-10 + Anhang A). */",
"export const ISO_SPEC_CONTROLS: readonly string[] = Object.keys(SPECS);",
""]
out_sp = os.path.normpath(os.path.join(BASE, "..", "..", "src", "lib", "control-specs-iso.ts"))
if not CHECK and LANG == "de":
with open(out_sp, "w", encoding="utf-8") as fh:
fh.write("\n".join(sp))
print("Geaenderte Dateien:", len(changed))
for c in changed:
print(" ", c)
print("mapping-iso.json:", len(anforderungen), "Anforderungen")
print("Statement-of-Applicability-ISO.md:", len(ctl), "Controls")
print("src/lib/control-titles-iso.ts:", len(cw), "Titel")
print("src/lib/iso-isa-crosswalk.ts:", len(pairs), "mit ISA-Bezug,", len(only), "ISO-eigen")
return 0
def patch_policy(text, code, by_section):
"""Bestehende Abschnitte um ISO-Bloecke ergaenzen und neue ISO-Abschnitte anhaengen."""
lines = text.split("\n")
out = []
# Abschnittsgrenzen finden
sec_starts = [j for j, l in enumerate(lines) if l.startswith("### ")]
sec_bounds = []
for k, s in enumerate(sec_starts):
e = sec_starts[k + 1] if k + 1 < len(sec_starts) else len(lines)
sec_bounds.append((s, e))
cursor = 0
for (s, e) in sec_bounds:
out.extend(lines[cursor:s])
block = lines[s:e]
ctrl = None
for l in block:
m = re.match(r"^<!--\s*IMPL\s+([^\s]+)\s*-->", l)
if m and not m.group(1).endswith("-elev"):
ctrl = m.group(1); break
entries = by_section.get((code, ctrl), []) if ctrl else []
if ctrl:
block = patch_section(block, entries)
out.extend(block)
cursor = e
out.extend(lines[cursor:])
text = "\n".join(out)
# Neue ISO-Abschnitte vor „## 4. Verbindlichkeit" einfuegen
new_keys = [k for (p, k) in by_section if p == code and k.startswith("ISO-")]
if new_keys:
order = [k for k in NEW_SECTIONS if k in new_keys]
base_no = 3
idx = max((int(m.group(2)) for m in re.finditer(r"^### (\d+)\.(\d+)", text, re.M)), default=0)
chunks = []
for k in order:
idx += 1
title, impl = NEW_SECTIONS[k]
ents = by_section[(code, k)]
refs = ", ".join(e["ref"] for e in sorted(ents, key=lambda x: x["_sort"]))
chunk = [S_SEC_A, "{{#if FLAG_FW_ISO27001}}", "",
"### %d.%d %s" % (base_no, idx, title), "",
"%s %s %s" % (L["ref_label"], L["iso_name"], refs), "",
L["req"], ""]
chunk += iso_bullets(ents)
chunk += ["", L["impl_head"], "", "<!-- IMPL %s -->" % k, impl, "",
"{{/if}}", S_SEC_E, ""]
chunks.append("\n".join(chunk))
anchor = re.search(r"^## 4\. Verbindlichkeit", text, re.M)
pos = anchor.start() if anchor else len(text)
text = text[:pos] + "".join(chunks) + text[pos:]
return text
def patch_section(block, entries):
"""Innerhalb eines Abschnitts: Ueberschrift konditionieren, ISA-Block klammern, ISO-Block anfuegen."""
refs = ", ".join(e["ref"] for e in sorted(entries, key=lambda x: x["_sort"]))
# 1. Ueberschrift entklammern, Anforderungsbezug in eine eigene Zeile darunter ziehen
m = re.match(r"^(### .*?)\s*(\(ISA [^)]*\))\s*$", block[0])
if m:
isa = m.group(2)[1:-1].replace("ISA ", L["isa_name"] + " ")
iso = ("%s %s" % (L["iso_name"], refs)) if refs else L["no_annex"]
ref_line = (L["ref_label"] + " {{#if FLAG_FW_TISAX}}%s{{/if}}"
"{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}%s{{/if}}") % (isa, iso)
block[0] = m.group(1)
j = 1
while j < len(block) and block[j].strip() == "":
j += 1
block[1:j] = ["", "<!-- FW:REF-START ORIG:%s -->" % m.group(2), ref_line, S_REF_E, ""]
# 2. Anforderungsbereich abgrenzen
try:
a = next(j for j, l in enumerate(block) if l.strip() == L["req"])
u = next(j for j, l in enumerate(block) if l.startswith(L["impl"]))
except StopIteration:
return block
start = a + 1
while start < u and block[start].strip() == "":
start += 1
end = u
while end - 1 > start and block[end - 1].strip() == "":
end -= 1
req = block[start:end]
wrapped = [S_TIS_A, "{{#if FLAG_FW_TISAX}}", LBL_TIS, ""] + req + ["{{/if}}", S_TIS_E]
if entries:
wrapped += [S_ISO_A, "{{#if FLAG_FW_ISO27001}}", LBL_ISO, ""] + iso_bullets(entries) + ["{{/if}}", S_ISO_E]
return block[:start] + wrapped + block[end:]
def patch_l00(text, entries):
"""L00 erhaelt einen ISO-Anhang (Politik, Ziele, Kommunikation, A.5.1)."""
if not entries:
return text
title, impl = NEW_SECTIONS["ISO-LEITLINIE"]
refs = ", ".join(e["ref"] for e in sorted(entries, key=lambda x: x["_sort"]))
chunk = [S_SEC_A, "{{#if FLAG_FW_ISO27001}}", "",
L["appendix"] % title, "",
"%s %s %s" % (L["ref_label"], L["iso_name"], refs), "",
L["req"], ""]
chunk += iso_bullets(entries)
chunk += ["", L["impl_head"], "", "<!-- IMPL ISO-LEITLINIE -->", impl, "",
"{{/if}}", S_SEC_E, ""]
return text.rstrip("\n") + "\n\n" + "\n".join(chunk)
if __name__ == "__main__":
sys.exit(main())
seed/isms-vorlagenpaket-v2/_generate_v2.py
+553
View File
@@ -0,0 +1,553 @@
# -*- coding: utf-8 -*-
"""
Generator ISMS-Vorlagenpaket v2.
Erzeugt: richtlinien/*.md (mit Hidden-IDs + {{LINK:...}}), mapping.json, ISA-Mapping-Matrix.
Konvention: UPPER_SNAKE-Variablen, {{#if FLAG_x}}...{{/if}} Bedingungsbloecke.
"""
import os, json
BASE = os.path.dirname(__file__)
RDIR = os.path.join(BASE, "richtlinien")
os.makedirs(RDIR, exist_ok=True)
# ---------------------------------------------------------------------------
# Datenmodell
# control = {"num","title","reqs":[{"t":"M"|"S","req":..,"impl":..}]}
# Jede Anforderung erhaelt eine ID <num>-<M|S><laufnr> und Hidden-Anker.
# ---------------------------------------------------------------------------
POLICIES = []
def pol(**k): POLICIES.append(k)
pol(id="R01", fn="R01_ISMS-Organisation-und-Rollen",
title="ISMS-Organisation und Rollen", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt Aufbau, Steuerung und Verantwortlichkeiten des Informationssicherheits-Managementsystems (ISMS) der {{ORG_NAME}} sowie die Beruecksichtigung der Informationssicherheit in Projekten.",
related=["L00","R03","R13"],
roles=[("{{ROLE_MANAGEMENT}}","Beauftragung und Gesamtverantwortung ISMS, Ressourcen, Managementbewertung"),
("{{ROLE_ISB}}","Operative Steuerung des ISMS, Pflege der Verantwortlichkeiten"),
("{{ROLE_IT_LEAD}}","Technische Umsetzung ISMS-relevanter Massnahmen"),
("Asset Owner / Prozessverantwortliche","Pflege zugeordneter Assets/Prozesse im ISMS-Tool")],
controls=[
{"num":"1.2.1","title":"Steuerung der Informationssicherheit","reqs":[
{"t":"M","req":"Der Geltungsbereich des ISMS (Organisation, Standorte, Prozesse) ist bestimmt und dokumentiert.",
"impl":"Der ISMS-Geltungsbereich ist im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und wird dort gepflegt."},
{"t":"M","req":"Das ISMS wird durch die Leitung initiiert, gesteuert und ueberwacht; erforderliche Ressourcen werden bereitgestellt.",
"impl":"Die {{ROLE_MANAGEMENT}} hat das ISMS beauftragt, stellt die erforderlichen Ressourcen bereit und traegt die Gesamtverantwortung; die operative Steuerung liegt bei {{ROLE_ISB}}."},
{"t":"M","req":"Die Wirksamkeit des ISMS wird regelmaessig durch die Leitung bewertet (Managementbewertung).",
"impl":"Die Wirksamkeit des ISMS wird mindestens {{REVIEW_CYCLE}} in einer dokumentierten Managementbewertung geprueft; die Ergebnisse werden im ISMS-Tool festgehalten."},
{"t":"S","req":"Informationssicherheitsziele sind messbar formuliert und werden nachverfolgt (KPI).",
"impl":"Informationssicherheitsziele und Kennzahlen (KPI) sind definiert und werden im ISMS-Tool nachverfolgt."},
]},
{"num":"1.2.2","title":"Organisation der Verantwortlichkeiten","reqs":[
{"t":"M","req":"Verantwortlichkeiten fuer Informationssicherheit sind definiert, zugewiesen und dokumentiert.",
"impl":"Die Verantwortlichkeiten sind in der Rollenuebersicht (Abschnitt 5) und im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und bekannt gemacht."},
{"t":"M","req":"Eine fuer Informationssicherheit verantwortliche Rolle ist benannt, verfuegt ueber ausreichende Kompetenzen und einen direkten Berichtsweg zur Leitung.",
"impl":"Die Rolle {{ROLE_ISB}} ist benannt und berichtet direkt an die {{ROLE_MANAGEMENT}}."},
{"t":"S","req":"In Konflikt stehende Aufgaben und Verantwortungsbereiche sind getrennt (Funktionstrennung).",
"impl":"In Konflikt stehende Taetigkeiten (z. B. Umsetzung und Kontrolle) werden getrennt; unvermeidbare Doppelrollen werden durch kompensierende Kontrollen abgesichert."},
{"t":"S","req":"Kontakte zu relevanten Behoerden und Interessengruppen werden gepflegt.",
"impl":"Relevante externe Kontakte (Behoerden, CERT, Branchengremien) werden durch {{ROLE_ISB}} gepflegt."},
]},
{"num":"1.2.3","title":"Informationssicherheit in Projekten","reqs":[
{"t":"M","req":"Projekte werden unter Beruecksichtigung ihres Informationssicherheitsbedarfs klassifiziert.",
"impl":"Projekte werden zu Beginn hinsichtlich ihres Informationssicherheitsbedarfs bewertet und klassifiziert."},
{"t":"M","req":"In Projekten werden Informationssicherheitsanforderungen ermittelt und beruecksichtigt.",
"impl":"Bei erhoehtem Schutzbedarf wird {{ROLE_ISB}} eingebunden; die Anforderungen werden ermittelt und im ISMS-Tool nachgehalten."},
{"t":"S","req":"Verfahren und Kriterien zur Klassifizierung von Projekten sind dokumentiert und werden angewandt.",
"impl":"Die Kriterien fuer die Projekteinstufung sind dokumentiert und werden einheitlich angewandt."},
]},
])
pol(id="R02", fn="R02_Asset-und-Klassifizierungsrichtlinie",
title="Asset- und Klassifizierungsrichtlinie", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt Identifikation, Inventarisierung, Klassifizierung und den geschuetzten Umgang mit Informationswerten und Assets der {{ORG_NAME}} sowie die Zulassung von Hard- und Software.",
related=["R01","R08","R11"],
roles=[("{{ROLE_IT_LEAD}}","Pflege des Asset-Inventars, Zulassung Hard-/Software"),
("{{ROLE_ISB}}","Vorgabe des Klassifizierungsschemas"),
("Asset Owner","Bewertung und Pflege einzelner Assets im ISMS-Tool")],
controls=[
{"num":"1.3.1","title":"Identifikation von Assets","reqs":[
{"t":"M","req":"Informationswerte und weitere Assets, die Informationen verarbeiten, sind identifiziert und erfasst.",
"impl":"Informationswerte und Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar erfasst."},
{"t":"M","req":"Fuer jedes Asset ist ein Verantwortlicher (Owner) benannt.",
"impl":"Jedem Asset ist im ISMS-Tool ein Owner zugeordnet."},
{"t":"S","req":"Ein Katalog der relevanten Informationswerte wird gepflegt und regelmaessig aktualisiert.",
"impl":"Das Asset-Inventar wird laufend gepflegt und mindestens {{REVIEW_CYCLE}} auf Aktualitaet geprueft."},
]},
{"num":"1.3.2","title":"Klassifizierung","reqs":[
{"t":"M","req":"Informationswerte sind nach Schutzbedarf (Vertraulichkeit, Integritaet, Verfuegbarkeit) klassifiziert.",
"impl":"Es gilt ein vierstufiges Klassifizierungsschema (Oeffentlich / Intern / Vertraulich / Streng vertraulich); die Einstufung erfolgt im ISMS-Tool."},
{"t":"M","req":"Abhaengig von der Klassifizierung sind Vorgaben zu Kennzeichnung, Handhabung, Speicherung, Uebertragung und Loeschung definiert.",
"impl":"Handhabungsvorgaben je Schutzklasse sind definiert und den Mitarbeitenden bekannt gemacht."},
{"t":"S","req":"Die Klassifizierung wird bei wesentlichen Aenderungen ueberprueft und angepasst.",
"impl":"Bei wesentlichen Aenderungen wird die Klassifizierung durch den Asset Owner ueberprueft."},
]},
{"num":"1.3.3","title":"Zugelassene Hardware","reqs":[
{"t":"M","req":"Es ist sichergestellt, dass nur bewertete und freigegebene externe Hardware/IT-Komponenten eingesetzt werden.",
"impl":"Externe Hardware wird vor Einsatz bewertet und freigegeben; eine Freigabeliste wird im ISMS-Tool gefuehrt."},
{"t":"S","req":"Nicht freigegebene Geraete werden technisch unterbunden.",
"impl":"Der Anschluss nicht freigegebener Geraete wird soweit moeglich technisch unterbunden."},
]},
{"num":"1.3.4","title":"Zugelassene Software","reqs":[
{"t":"M","req":"Es ist sichergestellt, dass nur bewertete und freigegebene Software eingesetzt wird.",
"impl":"Software wird vor Einsatz freigegeben; eine Liste zugelassener Software wird gepflegt."},
{"t":"S","req":"Die Installation nicht freigegebener Software wird technisch eingeschraenkt.",
"impl":"Die Installation von Software ist fuer Standardnutzer technisch eingeschraenkt."},
]},
])
pol(id="R03", fn="R03_Risikomanagement-und-Auditrichtlinie",
title="Risikomanagement- und Auditrichtlinie", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken sowie die interne und unabhaengige Ueberpruefung des ISMS.",
related=["R01","R04"],
roles=[("{{ROLE_ISB}}","Steuerung des Risikomanagements, Pflege des Risikoregisters"),
("{{ROLE_MANAGEMENT}}","Entscheidung ueber Risikoakzeptanz"),
("Asset/Prozessverantwortliche","Mitwirkung bei Risikobewertung")],
controls=[
{"num":"1.4.1","title":"Risikomanagement","reqs":[
{"t":"M","req":"Es existiert ein dokumentiertes Verfahren zur Identifikation, Analyse, Bewertung und Behandlung von Informationssicherheitsrisiken.",
"impl":"Das Risikomanagement-Verfahren ist dokumentiert; Risiken werden im ISMS-Tool ({{TOOL_NAME}}) bewertet und nachverfolgt."},
{"t":"M","req":"Risiken werden in einem Risikoregister erfasst; Behandlungsoptionen und Massnahmen sind festgelegt.",
"impl":"Alle Risiken werden im Risikoregister erfasst; je Risiko sind Behandlungsoption (reduzieren/vermeiden/uebertragen/akzeptieren) und Massnahmen hinterlegt."},
{"t":"M","req":"Die Risikobewertung wird regelmaessig und anlassbezogen aktualisiert; die Risikoakzeptanz erfolgt durch die Leitung.",
"impl":"Die Bewertung wird mindestens {{REVIEW_CYCLE}} und anlassbezogen aktualisiert; die {{ROLE_MANAGEMENT}} akzeptiert Restrisiken dokumentiert."},
{"t":"S","req":"Kriterien fuer Eintrittswahrscheinlichkeit, Schadenshoehe und Akzeptanzschwellen sind definiert.",
"impl":"Bewertungs- und Akzeptanzkriterien sind definiert und im ISMS-Tool hinterlegt."},
]},
{"num":"1.5.1","title":"Compliance-Pruefung im IS-Betrieb","reqs":[
{"t":"M","req":"Die Einhaltung der Informationssicherheitsvorgaben wird regelmaessig geprueft.",
"impl":"Die Einhaltung wird durch interne Audits und Kontrollen regelmaessig geprueft."},
{"t":"S","req":"Ein Auditprogramm mit Umfang, Turnus und Verantwortlichkeiten ist etabliert; Feststellungen werden nachverfolgt.",
"impl":"Ein Auditprogramm ist etabliert; Feststellungen werden im ISMS-Tool nachverfolgt."},
]},
{"num":"1.5.2","title":"Unabhaengige Ueberpruefung","reqs":[
{"t":"M","req":"Das ISMS wird durch eine unabhaengige Stelle ueberprueft.",
"impl":"Das ISMS wird durch eine unabhaengige Stelle (interne Revision oder externe Auditierung) ueberprueft."},
{"t":"S","req":"Ergebnisse fliessen in die Managementbewertung und den Verbesserungsprozess ein.",
"impl":"Die Ergebnisse werden in der Managementbewertung behandelt und fliessen in Verbesserungsmassnahmen ein."},
]},
])
pol(id="R04", fn="R04_Incident-Notfall-und-Kontinuitaetsrichtlinie",
title="Incident-, Notfall- und Kontinuitaetsrichtlinie", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt Meldung und Behandlung von Sicherheitsereignissen, das Krisenmanagement sowie die Notfall- und Kontinuitaetsplanung fuer IT-Dienste.",
related=["R03","R10"],
roles=[("{{ROLE_ISB}}","Koordination der Vorfallsbehandlung"),
("{{ROLE_IT_LEAD}}","IT-Notfall- und Wiederanlaufplanung"),
("{{ROLE_MANAGEMENT}}","Einberufung Krisenstab")],
controls=[
{"num":"1.6.1","title":"Meldung von Ereignissen","reqs":[
{"t":"M","req":"Sicherheitsrelevante Ereignisse und Beobachtungen koennen ueber einen definierten Meldeweg gemeldet werden.",
"impl":"Ein Meldeweg fuer Sicherheitsereignisse ist eingerichtet (z. B. im ISMS-Tool {{TOOL_NAME}}) und bekannt gemacht."},
{"t":"M","req":"Der Meldeweg ist bekannt gemacht und niedrigschwellig erreichbar.",
"impl":"Der Meldeweg ist allen Mitarbeitenden bekannt und niedrigschwellig erreichbar."},
{"t":"S","req":"Meldungen werden zentral erfasst und kategorisiert.",
"impl":"Meldungen werden zentral im ISMS-Tool erfasst und kategorisiert."},
]},
{"num":"1.6.2","title":"Behandlung von Sicherheitsereignissen","reqs":[
{"t":"M","req":"Gemeldete Sicherheitsereignisse werden bewertet, priorisiert, behandelt und dokumentiert.",
"impl":"Ereignisse werden nach einem definierten Verfahren bewertet, priorisiert, behandelt und im ISMS-Tool dokumentiert."},
{"t":"M","req":"Verantwortlichkeiten und Eskalationswege fuer die Vorfallsbehandlung sind definiert.",
"impl":"Verantwortlichkeiten und Eskalationswege sind definiert; {{ROLE_ISB}} koordiniert die Behandlung."},
{"t":"S","req":"Erkenntnisse aus Vorfaellen werden ausgewertet (Lessons Learned) und fuehren zu Verbesserungen.",
"impl":"Nach relevanten Vorfaellen erfolgt eine Auswertung (Lessons Learned) mit Ableitung von Verbesserungen."},
{"t":"S","req":"Meldepflichten (z. B. an Kunden/OEM, Behoerden) sind beruecksichtigt.",
"impl":"Bestehende Meldepflichten gegenueber Kunden/OEM und Behoerden werden im Behandlungsprozess beruecksichtigt."},
]},
{"num":"1.6.3","title":"Krisenmanagement","reqs":[
{"t":"M","req":"Die Organisation ist auf die Bewaeltigung von Krisensituationen vorbereitet (Rollen, Kommunikation, Entscheidungswege).",
"impl":"Ein Krisenmanagement mit Rollen, Kommunikations- und Entscheidungswegen ist definiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen."},
{"t":"S","req":"Krisen-/Notfallplaene werden regelmaessig geuebt und aktualisiert.",
"impl":"Krisen- und Notfallplaene werden mindestens {{REVIEW_CYCLE}} geuebt und aktualisiert."},
]},
{"num":"5.2.8","title":"Kontinuitaetsplanung IT","reqs":[
{"t":"M","req":"Fuer kritische IT-Dienste besteht eine Kontinuitaetsplanung (Wiederanlaufziele, Verantwortliche, Massnahmen).",
"impl":"Fuer kritische IT-Dienste bestehen Wiederanlaufziele, Verantwortliche und Massnahmen; {{ROLE_IT_LEAD}} verantwortet die Planung."},
{"t":"S","req":"Wiederanlaufmassnahmen werden regelmaessig getestet; Ergebnisse werden dokumentiert.",
"impl":"Wiederanlaufmassnahmen werden mindestens {{REVIEW_CYCLE}} getestet; Ergebnisse werden dokumentiert."},
]},
])
pol(id="R05", fn="R05_Personalsicherheit-und-Awareness",
title="Personalsicherheit und Awareness", owner="ROLE_HR_LEAD",
purpose="Diese Richtlinie regelt Eignung und Qualifikation fuer sicherheitsrelevante Taetigkeiten, die vertragliche Verpflichtung des Personals sowie Schulung und Sensibilisierung.",
related=["R01","R06"],
roles=[("{{ROLE_HR_LEAD}}","Vertragliche Verpflichtung, Eignungspruefungen"),
("{{ROLE_ISB}}","Inhalte und Nachweis von Schulung und Awareness"),
("Fuehrungskraefte","Umsetzung im Verantwortungsbereich")],
controls=[
{"num":"2.1.1","title":"Qualifikation fuer sensible Taetigkeiten","reqs":[
{"t":"M","req":"Fuer sicherheitsrelevante/sensible Taetigkeiten ist die erforderliche Qualifikation und Zuverlaessigkeit der Beschaeftigten sichergestellt.",
"impl":"Fuer sensible Taetigkeiten werden Qualifikation und Zuverlaessigkeit im rechtlich zulaessigen Rahmen sichergestellt."},
{"t":"S","req":"Anforderungen an Positionen sind beschrieben; angemessene Ueberpruefungen erfolgen im rechtlich zulaessigen Rahmen.",
"impl":"Sicherheitsanforderungen an Positionen sind beschrieben; Ueberpruefungen erfolgen anlassbezogen."},
]},
{"num":"2.1.2","title":"Vertragliche Verpflichtung","reqs":[
{"t":"M","req":"Alle Beschaeftigten sind vertraglich zur Einhaltung der Informationssicherheit und zur Vertraulichkeit verpflichtet.",
"impl":"Alle Beschaeftigten werden bei Eintritt vertraglich zur Vertraulichkeit und Einhaltung der Informationssicherheit verpflichtet."},
{"t":"S","req":"Verpflichtungen gelten auch nach Beendigung des Arbeitsverhaeltnisses fort und umfassen Rueckgabepflichten.",
"impl":"Die Vertraulichkeitsverpflichtung gilt nachvertraglich fort; Rueckgabepflichten sind geregelt."},
]},
{"num":"2.1.3","title":"Sensibilisierung und Schulung","reqs":[
{"t":"M","req":"Beschaeftigte werden hinsichtlich Informationssicherheit sensibilisiert und geschult.",
"impl":"Beschaeftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} geschult; Nachweise werden im ISMS-Tool ({{TOOL_NAME}}) gefuehrt."},
{"t":"S","req":"Schulungsinhalte sind rollenspezifisch; die Wirksamkeit wird ueberprueft (z. B. Phishing-Tests).",
"impl":"Schulungen sind rollenspezifisch; die Wirksamkeit wird z. B. durch Phishing-Simulationen ueberprueft."},
]},
])
pol(id="R06", fn="R06_Mobiles-Arbeiten-und-mobile-Geraete",
title="Mobiles Arbeiten und mobile Geraete", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt mobiles Arbeiten (Homeoffice/Telearbeit) sowie den sicheren Umgang mit mobilen IT-Geraeten und Datentraegern.",
related=["R05","R07","R08"],
roles=[("{{ROLE_ISB}}","Festlegung der Sicherheitsanforderungen"),
("{{ROLE_IT_LEAD}}","Technische Umsetzung (VPN, MDM)"),
("Mitarbeitende","Einhaltung der Vorgaben")],
controls=[
{"num":"2.1.4","title":"Mobiles Arbeiten","flag":"FLAG_MOBILE_WORK","reqs":[
{"t":"M","req":"Mobiles Arbeiten ist geregelt (zulaessige Orte, Umgang mit Informationen, Absicherung der Verbindung).",
"impl":"Mobiles Arbeiten ist geregelt; der Zugriff erfolgt ueber gesicherte Verbindungen ({{TECH_VPN}}) und freigegebene Geraete."},
{"t":"M","req":"Der Zugriff auf Unternehmensinformationen erfolgt ausschliesslich ueber gesicherte Verbindungen und freigegebene Geraete.",
"impl":"Der Zugriff auf Unternehmensinformationen ist auf freigegebene, abgesicherte Geraete beschraenkt."},
{"t":"S","req":"Sichtschutz, Clean-Desk/Clean-Screen und Regeln fuer oeffentliche Umgebungen sind definiert.",
"impl":"Regeln zu Sichtschutz, Clean-Desk/Clean-Screen und zum Arbeiten in oeffentlichen Umgebungen sind definiert."},
]},
{"num":"3.1.4","title":"Mobile Geraete und Datentraeger","flag":"FLAG_MOBILE_DEVICES","reqs":[
{"t":"M","req":"Der Umgang mit mobilen IT-Geraeten und mobilen Datentraegern ist geregelt (Verschluesselung, Verlustmeldung, Freigabe).",
"impl":"Mobile Geraete sind verschluesselt und ueber {{TECH_MDM}} verwaltet; Verlustmeldung und Freigabe sind geregelt."},
{"t":"M","req":"Mobile Geraete sind verschluesselt und koennen bei Verlust gesperrt/geloescht werden.",
"impl":"Bei Verlust koennen Geraete ueber {{TECH_MDM}} gesperrt und geloescht werden."},
{"t":"S","req":"Der Einsatz privater Geraete (BYOD) ist geregelt oder untersagt; Wechseldatentraeger werden kontrolliert.",
"impl":"Der Einsatz privater Geraete ist geregelt; Wechseldatentraeger werden kontrolliert und nur verschluesselt zugelassen."},
]},
])
pol(id="R07", fn="R07_Physische-Sicherheit",
title="Physische Sicherheit", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt den physischen Schutz von Informationen und informationsverarbeitenden Einrichtungen durch Sicherheitszonen, Zutrittsschutz und den Umgang mit unterstuetzenden Betriebsmitteln.",
related=["R02","R06"],
roles=[("{{ROLE_IT_LEAD}}","Zonenkonzept, Zutrittsschutz, Betriebsmittel"),
("{{ROLE_ISB}}","Vorgabe der Anforderungen")],
controls=[
{"num":"3.1.1","title":"Sicherheitszonen und Zutritt","reqs":[
{"t":"M","req":"Sicherheitszonen sind definiert und der Zutritt zu schuetzenswerten Bereichen ist reglementiert und nachvollziehbar.",
"impl":"Sicherheitszonen sind definiert; der Zutritt zu schuetzenswerten Bereichen ist reglementiert und wird protokolliert."},
{"t":"M","req":"Zutrittsrechte werden nach Bedarf vergeben, dokumentiert und bei Wegfall entzogen.",
"impl":"Zutrittsrechte werden bedarfsorientiert vergeben, dokumentiert und bei Wegfall entzogen."},
{"t":"S","req":"Zutritte werden protokolliert; Besucher werden begleitet; technische Schutzmassnahmen sind vorhanden.",
"impl":"Besucher werden registriert und begleitet; technische Schutzmassnahmen (z. B. Alarm/Video im rechtlichen Rahmen) sind vorhanden."},
]},
{"num":"3.1.3","title":"Umgang mit unterstuetzenden Betriebsmitteln","reqs":[
{"t":"M","req":"Der Umgang mit unterstuetzenden Assets (z. B. Verkabelung, Strom-/Klimaversorgung, Serverraeume) ist geregelt und schuetzt vor Ausfall und unbefugtem Zugriff.",
"impl":"Serverraeume und Versorgungseinrichtungen sind zutrittsgeschuetzt und gegen Ausfall abgesichert."},
{"t":"S","req":"Versorgungseinrichtungen werden gewartet und ueberwacht; Redundanzen bestehen fuer kritische Bereiche.",
"impl":"Versorgungseinrichtungen werden gewartet und ueberwacht; fuer kritische Bereiche bestehen Redundanzen (z. B. USV)."},
]},
])
pol(id="R08", fn="R08_Identitaets-und-Zugriffsmanagement",
title="Identitaets- und Zugriffsmanagement", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt Identifikationsmittel, die sichere Anmeldung, die Verwaltung von Benutzerkonten und Anmeldeinformationen sowie die Vergabe und Kontrolle von Zugriffsrechten.",
related=["R02","R05","R10"],
roles=[("{{ROLE_IT_LEAD}}","Technische Umsetzung IAM"),
("Fachbereiche","Fachliche Freigabe von Berechtigungen"),
("{{ROLE_ISB}}","Ueberwachung der Einhaltung")],
controls=[
{"num":"4.1.1","title":"Identifikationsmittel","reqs":[
{"t":"M","req":"Der Einsatz von Identifikationsmitteln (Benutzerkennungen, Token, Zertifikate) ist geregelt und eindeutig personenbezogen.",
"impl":"Identifikationsmittel werden eindeutig personenbezogen vergeben; Sammelkonten werden vermieden."},
{"t":"S","req":"Ausgabe, Ruecknahme und Sperrung von Identifikationsmitteln sind dokumentiert.",
"impl":"Ausgabe, Ruecknahme und Sperrung werden dokumentiert."},
]},
{"num":"4.1.2","title":"Sichere Anmeldung","reqs":[
{"t":"M","req":"Der Zugang zu IT-Diensten und IT-Systemen ist durch sichere Authentifizierungsverfahren geschuetzt.",
"impl":"Der Zugang ist durch sichere Authentifizierung geschuetzt; Passwortanforderungen sind zentral vorgegeben."},
{"t":"M","req":"Fuer erhoehten Schutzbedarf und Fernzugriffe wird Mehr-Faktor-Authentifizierung (MFA) eingesetzt.",
"impl":"Fuer Fernzugriffe und erhoehten Schutzbedarf wird MFA ueber {{TECH_MFA}} durchgesetzt."},
{"t":"S","req":"Passwortanforderungen, Sperrmechanismen und Sitzungsverwaltung sind definiert.",
"impl":"Passwortrichtlinie, Sperrmechanismen und Sitzungs-Timeouts sind zentral konfiguriert."},
]},
{"num":"4.1.3","title":"Konten und Anmeldeinformationen","reqs":[
{"t":"M","req":"Benutzerkonten und Anmeldeinformationen werden sicher verwaltet (Erstellung, Aenderung, Sperrung, Loeschung).",
"impl":"Konten werden ueber einen definierten Lebenszyklus (Joiner/Mover/Leaver) verwaltet."},
{"t":"S","req":"Privilegierte und technische Konten werden gesondert verwaltet und ueberwacht.",
"impl":"Privilegierte und technische Konten werden gesondert verwaltet und ihre Nutzung ueberwacht."},
]},
{"num":"4.2.1","title":"Zugriffsrechte","reqs":[
{"t":"M","req":"Zugriffsrechte werden nach dem Minimalprinzip (need-to-know / least privilege) vergeben; Verfahren fuer Antrag, Pruefung und Genehmigung bestehen.",
"impl":"Zugriffsrechte werden nach dem Minimalprinzip vergeben; Antrag, Pruefung und Genehmigung erfolgen ueber ein definiertes Verfahren."},
{"t":"M","req":"Zugriffsrechte werden bei Wegfall des Bedarfs entzogen und regelmaessig ueberprueft (Rezertifizierung){{IF_CUSTOMER}}.",
"impl":"Berechtigungen werden bei Wegfall entzogen und mindestens {{REVIEW_CYCLE}} rezertifiziert{{IF_CUSTOMER_IMPL}}."},
{"t":"S","req":"Berechtigungen werden ueber Rollen vergeben; normale Konten erhalten keine privilegierten Rechte.",
"impl":"Berechtigungen werden rollenbasiert vergeben; Standardkonten erhalten keine privilegierten Rechte."},
]},
])
pol(id="R09", fn="R09_Kryptografie-und-Uebertragungsrichtlinie",
title="Kryptografie- und Uebertragungsrichtlinie", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt den Einsatz kryptografischer Verfahren, die Schluesselverwaltung sowie den Schutz von Informationen bei der Uebertragung.",
related=["R08","R10","R12"],
roles=[("{{ROLE_IT_LEAD}}","Verfahren und Schluesselverwaltung"),
("{{ROLE_ISB}}","Vorgabe zulaessiger Algorithmen/Staerken")],
controls=[
{"num":"5.1.1","title":"Einsatz kryptografischer Verfahren","reqs":[
{"t":"M","req":"Der Einsatz von Kryptografie ist geregelt; zulaessige Verfahren und Schluessellaengen entsprechen dem Stand der Technik.",
"impl":"Zulaessige Verfahren und Schluessellaengen entsprechen dem Stand der Technik ({{TECH_CRYPTO}}) und sind vorgegeben."},
{"t":"M","req":"Schluessel werden ueber ihren gesamten Lebenszyklus sicher verwaltet.",
"impl":"Schluessel werden ueber ihren Lebenszyklus (Erzeugung, Verteilung, Speicherung, Sperrung, Vernichtung) sicher verwaltet."},
{"t":"S","req":"Ein Kryptokonzept ist dokumentiert{{IF_PKI}}.",
"impl":"Ein Kryptokonzept ist dokumentiert{{IF_PKI_IMPL}}."},
]},
{"num":"5.1.2","title":"Schutz bei Uebertragung","reqs":[
{"t":"M","req":"Informationen werden abhaengig vom Schutzbedarf bei der Uebertragung geschuetzt (z. B. Transportverschluesselung, gesicherte Kanaele).",
"impl":"Informationen werden schutzbedarfsgerecht per Transportverschluesselung (z. B. TLS) und gesicherte Kanaele geschuetzt."},
{"t":"S","req":"Regeln fuer sichere Uebertragungswege (E-Mail-Verschluesselung, sichere Dateiuebertragung) sind definiert.",
"impl":"Regeln fuer E-Mail-Verschluesselung und sichere Dateiuebertragung sind definiert."},
]},
])
pol(id="R10", fn="R10_Betriebssicherheit",
title="Betriebssicherheit", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt den sicheren IT-Betrieb: Change-Management, Trennung von Umgebungen, Malware-Schutz, Protokollierung, Schwachstellen- und Patch-Management, technische Pruefungen, Netzwerksicherheit sowie Datensicherung und Wiederherstellung.",
related=["R04","R08","R11"],
roles=[("{{ROLE_IT_LEAD}}","Sicherer IT-Betrieb"),
("{{ROLE_ISB}}","Ueberwachung der Einhaltung")],
controls=[
{"num":"5.2.1","title":"Change-Management","reqs":[
{"t":"M","req":"Aenderungen an IT-Systemen werden geregelt beantragt, bewertet, getestet, genehmigt und dokumentiert.",
"impl":"Aenderungen durchlaufen ein Change-Verfahren mit Bewertung, Test, Genehmigung und Dokumentation."}]},
{"num":"5.2.2","title":"Trennung der Umgebungen","reqs":[
{"t":"M","req":"Entwicklungs-, Test- und Produktionsumgebungen sind getrennt.",
"impl":"Entwicklung, Test und Produktion sind getrennt betrieben."},
{"t":"S","req":"Produktivdaten werden nicht ungeschuetzt in Test-/Entwicklungsumgebungen verwendet.",
"impl":"Produktivdaten werden in Test-/Entwicklungsumgebungen nur anonymisiert/pseudonymisiert genutzt."}]},
{"num":"5.2.3","title":"Schutz vor Malware","reqs":[
{"t":"M","req":"Anforderungen zum Schutz vor Schadsoftware sind bestimmt; technische und organisatorische Massnahmen sind umgesetzt.",
"impl":"Malware-Schutz ist ueber {{TECH_MALWARE}} auf allen relevanten Systemen umgesetzt."},
{"t":"S","req":"Schutzsoftware wird automatisch aktualisiert; unnoetige Netzwerkdienste sind deaktiviert.",
"impl":"Schutzsoftware aktualisiert sich automatisch; unnoetige Netzwerkdienste sind deaktiviert."}]},
{"num":"5.2.4","title":"Protokollierung und Auswertung","reqs":[
{"t":"M","req":"Sicherheitsrelevante Ereignisse werden protokolliert und ausgewertet.",
"impl":"Sicherheitsrelevante Ereignisse werden protokolliert und ueber {{TECH_SIEM}} ausgewertet."},
{"t":"S","req":"Protokolle sind vor Manipulation geschuetzt; Aufbewahrungsfristen sind definiert.",
"impl":"Protokolle sind manipulationsgeschuetzt; Aufbewahrungsfristen sind definiert."}]},
{"num":"5.2.5","title":"Schwachstellen- und Patch-Management","reqs":[
{"t":"M","req":"Schwachstellen werden identifiziert und risikoorientiert behoben (Patch-Management).",
"impl":"Schwachstellen werden erfasst und risikoorientiert gepatcht; kritische Patches werden priorisiert."},
{"t":"S","req":"Es besteht ein regelmaessiges Schwachstellen-Scanning; kritische Patches werden priorisiert.",
"impl":"Ein regelmaessiges Schwachstellen-Scanning ist etabliert."}]},
{"num":"5.2.6","title":"Technische Ueberpruefung","reqs":[
{"t":"M","req":"IT-Systeme und Dienste werden technisch ueberprueft (z. B. Systemhaertung, Penetrationstests).",
"impl":"Systeme werden gehaertet und risikoorientiert technisch geprueft (z. B. Penetrationstests)."}]},
{"num":"5.2.7","title":"Netzwerksicherheit","reqs":[
{"t":"M","req":"Das Netzwerk wird gesteuert und abgesichert (Segmentierung, Zugangskontrolle, Absicherung nach aussen).",
"impl":"Das Netzwerk ist segmentiert, zugangskontrolliert und nach aussen abgesichert (Firewall)."},
{"t":"M","req":"{{IF_OT}}Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert.",
"impl":"{{IF_OT}}Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert.","cond":"FLAG_OT_USED"},
{"t":"S","req":"Ein aktueller Netzplan und ein Segmentierungskonzept liegen vor.",
"impl":"Ein aktueller Netzplan und ein Segmentierungskonzept werden gepflegt."}]},
{"num":"5.2.9","title":"Backup und Wiederherstellung","reqs":[
{"t":"M","req":"Daten und IT-Dienste werden gesichert; Wiederherstellung ist geregelt.",
"impl":"Daten und Dienste werden ueber {{TECH_BACKUP}} gesichert; die Wiederherstellung ist geregelt."},
{"t":"M","req":"Wiederherstellungstests werden regelmaessig durchgefuehrt.",
"impl":"Wiederherstellungstests werden mindestens {{REVIEW_CYCLE}} durchgefuehrt und dokumentiert."},
{"t":"S","req":"Backups werden geschuetzt/ausgelagert aufbewahrt (z. B. offline/immutable).",
"impl":"Backups werden geschuetzt und ausgelagert (offline/immutable) aufbewahrt."}]},
])
pol(id="R11", fn="R11_Sichere-Systembeschaffung-und-Entwicklung",
title="Sichere Systembeschaffung und Entwicklung", owner="ROLE_IT_LEAD",
purpose="Diese Richtlinie regelt die Beruecksichtigung der Informationssicherheit bei Beschaffung und Weiterentwicklung von IT-Systemen, Anforderungen an Netzdienste sowie Rueckgabe und sichere Loeschung von Informationen.",
related=["R02","R10","R12"],
roles=[("{{ROLE_IT_LEAD}}","Beschaffung/Entwicklung"),
("{{ROLE_ISB}}","Definition Sicherheitsanforderungen")],
controls=[
{"num":"5.3.1","title":"Sicherheit bei Beschaffung/Entwicklung","reqs":[
{"t":"M","req":"Bei Beschaffung oder Weiterentwicklung von IT-Systemen werden Informationssicherheitsanforderungen ermittelt und beruecksichtigt.",
"impl":"Sicherheitsanforderungen sind fester Bestandteil von Beschaffungs- und Aenderungsprozessen (Security by Design)."},
{"t":"M","req":"{{IF_DEV}}Fuer die Eigenentwicklung gelten Vorgaben fuer sichere Entwicklung (Secure Coding, Tests, Freigaben).",
"impl":"{{IF_DEV}}Fuer die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Tests und Freigaben.","cond":"FLAG_DEV_INHOUSE"},
{"t":"S","req":"Sicherheitsanforderungen sind Bestandteil des Beschaffungs-/Entwicklungsprozesses (Security by Design).",
"impl":"Sicherheitsanforderungen werden dokumentiert und ihre Umsetzung vor Freigabe geprueft."}]},
{"num":"5.3.2","title":"Anforderungen an Netzdienste","reqs":[
{"t":"M","req":"Sicherheitsanforderungen an Netzdienste (intern und extern) sind definiert.",
"impl":"Fuer genutzte Netzdienste sind Sicherheitsanforderungen definiert und vereinbart."}]},
{"num":"5.3.3","title":"Rueckgabe und sichere Loeschung","reqs":[
{"t":"M","req":"Rueckgabe und sichere Entfernung/Loeschung von Informationen und Assets sind geregelt.",
"impl":"Rueckgabe und sichere Loeschung (bei Vertragsende, Geraeteausmusterung) sind geregelt und werden nachgewiesen."},
{"t":"S","req":"Loeschverfahren entsprechen dem Schutzbedarf; Loeschungen werden nachgewiesen.",
"impl":"Loeschverfahren richten sich nach dem Schutzbedarf; Loeschungen werden dokumentiert."}]},
])
pol(id="R12", fn="R12_Cloud-KI-und-externe-IT-Dienste",
title="Cloud-, KI- und externe IT-Dienste", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt den Schutz von Informationen bei der Nutzung ausgelagerter oder geteilter externer IT-Dienste (Cloud) sowie beim Einsatz von KI-/GenAI-Diensten, einschliesslich Auswahl, Freigabe, zulaessiger Nutzung und Datenpreisgabe.",
related=["R09","R11","R13"],
roles=[("{{ROLE_ISB}}","Freigabe Cloud-/KI-Dienste, Pflege der Freigabeliste"),
("{{ROLE_IT_LEAD}}","Technische Absicherung"),
("Fachbereiche","Nutzung nur freigegebener Dienste")],
controls=[
{"num":"5.3.4","title":"Externe/geteilte IT-Dienste und Cloud","reqs":[
{"t":"M","req":"Bei geteilten externen IT-Diensten ist durch wirksame Mandantentrennung sichergestellt, dass Unbefugte anderer Organisationen nicht auf eigene Informationen zugreifen koennen.",
"impl":"Bei geteilten Diensten wird auf eine wirksame Mandantentrennung geachtet und diese vertraglich zugesichert."},
{"t":"M","req":"{{IF_CLOUD}}Cloud-Dienste werden vor Nutzung bewertet und freigegeben; nur freigegebene Dienste werden fuer Unternehmensinformationen genutzt.",
"impl":"{{IF_CLOUD}}Cloud-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation, Exit) und freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) gepflegt.","cond":"FLAG_CLOUD_USED"},
{"t":"S","req":"Das Segregationskonzept des Anbieters ist dokumentiert und wird bei Aenderungen angepasst.",
"impl":"Das Segregationskonzept des Anbieters wird dokumentiert und bei Aenderungen aktualisiert."}]},
{"num":"5.3.4-KI","title":"Nutzung von KI-/GenAI-Diensten","flag":"FLAG_AI_USED","reqs":[
{"t":"M","req":"Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutzt.",
"impl":"Der Einsatz von KI-/GenAI-Diensten ist geregelt; nur freigegebene Dienste (Freigabeliste im ISMS-Tool) duerfen genutzt werden."},
{"t":"M","req":"Die Eingabe vertraulicher oder personenbezogener Informationen in nicht freigegebene KI-Dienste ist untersagt; zulaessige Datenklassen je Dienst sind definiert.",
"impl":"Zulaessige Datenklassen je KI-Dienst sind definiert; die Eingabe vertraulicher/personenbezogener Daten in nicht freigegebene Dienste ist untersagt."},
{"t":"M","req":"Bei freigegebenen KI-Diensten ist geklaert, ob Eingaben zum Training genutzt werden; eine Trainings-/Weitergabe von Unternehmensdaten wird ausgeschlossen oder vertraglich untersagt.",
"impl":"Bei Freigabe wird geprueft und vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden."},
{"t":"S","req":"Ergebnisse werden vor geschaeftskritischer Verwendung geprueft (Human-in-the-Loop); der KI-Einsatz wird dokumentiert; regulatorische Anforderungen (z. B. EU AI Act) werden beruecksichtigt.",
"impl":"KI-Ergebnisse werden vor kritischer Verwendung durch Menschen geprueft; der KI-Einsatz wird dokumentiert und regulatorische Anforderungen (EU AI Act) beruecksichtigt."}]},
])
pol(id="R13", fn="R13_Lieferanten-und-Dienstleistersteuerung",
title="Lieferanten- und Dienstleistersteuerung", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt die Sicherstellung der Informationssicherheit bei Auftragnehmern und Lieferanten, Vertraulichkeitsvereinbarungen sowie die Abgrenzung von Verantwortlichkeiten mit externen IT-Dienstleistern.",
related=["R01","R12"],
roles=[("{{ROLE_ISB}}","Steuerung der Lieferantensicherheit, Pflege Lieferantenverzeichnis"),
("Einkauf","Vertragliche Einbindung der Anforderungen")],
controls=[
{"num":"6.1.1","title":"Informationssicherheit bei Lieferanten","reqs":[
{"t":"M","req":"Informationssicherheitsanforderungen an Auftragnehmer/Lieferanten sind ermittelt und werden vertraglich vereinbart und ueberwacht.",
"impl":"Sicherheitsanforderungen an Lieferanten werden ermittelt, vertraglich vereinbart und ueberwacht; das Lieferantenverzeichnis wird im ISMS-Tool ({{TOOL_NAME}}) gepflegt."},
{"t":"M","req":"Lieferanten werden risikoorientiert bewertet.",
"impl":"Lieferanten werden risikoorientiert (nach Schutzbedarf und Zugriff) bewertet."},
{"t":"S","req":"Die Einhaltung der Anforderungen wird regelmaessig ueberprueft (z. B. Nachweise, Audits, TISAX-Label).",
"impl":"Die Einhaltung wird regelmaessig ueberprueft (Nachweise, Audits, TISAX-Label)."}]},
{"num":"6.1.2","title":"Vertraulichkeit","reqs":[
{"t":"M","req":"Der Austausch von Informationen mit Externen ist durch Vertraulichkeitsvereinbarungen (NDA) abgesichert.",
"impl":"Vor dem Austausch schutzbeduerftiger Informationen werden NDAs abgeschlossen."},
{"t":"S","req":"NDA-Vorlagen sind standardisiert; Geltungsdauer und Rueckgabe-/Loeschpflichten sind geregelt.",
"impl":"Standardisierte NDA-Vorlagen mit Geltungsdauer und Rueckgabe-/Loeschpflichten werden verwendet."}]},
{"num":"6.1.3","title":"Abgrenzung der Verantwortlichkeiten","reqs":[
{"t":"M","req":"{{IF_EXTIT}}Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern sind klar abgegrenzt und dokumentiert.",
"impl":"{{IF_EXTIT}}Die Verantwortlichkeiten mit externen IT-Dienstleistern (Betriebs-, Sicherheits-, Meldepflichten) sind abgegrenzt und dokumentiert.","cond":"FLAG_EXTERNAL_IT"},
{"t":"S","req":"Schnittstellen, Eskalations- und Meldewege mit Dienstleistern sind vereinbart.",
"impl":"Schnittstellen sowie Eskalations- und Meldewege sind vertraglich vereinbart."}]},
])
pol(id="R14", fn="R14_Compliance-und-Datenschutz",
title="Compliance und Datenschutz", owner="ROLE_ISB",
purpose="Diese Richtlinie regelt die Einhaltung regulatorischer und vertraglicher Vorgaben sowie den Schutz personenbezogener Daten.",
related=["L00","R03"],
roles=[("{{ROLE_ISB}}","Compliance-Register"),
("{{ROLE_DPO}}","Datenschutz")],
controls=[
{"num":"7.1.1","title":"Regulatorische und vertragliche Compliance","reqs":[
{"t":"M","req":"Relevante gesetzliche, regulatorische und vertragliche Anforderungen an die Informationssicherheit sind identifiziert, dokumentiert und werden eingehalten.",
"impl":"Relevante Anforderungen werden in einem Compliance-/Rechtsregister im ISMS-Tool ({{TOOL_NAME}}) erfasst und ihre Einhaltung nachverfolgt."},
{"t":"S","req":"Ein Compliance-/Rechtsregister wird gepflegt und regelmaessig aktualisiert; Verantwortliche sind benannt.",
"impl":"Das Register wird mindestens {{REVIEW_CYCLE}} aktualisiert; Verantwortliche sind benannt."}]},
{"num":"7.1.2","title":"Schutz personenbezogener Daten","flag":"FLAG_PERSONAL_DATA","reqs":[
{"t":"M","req":"Beim Umgang mit personenbezogenen Daten werden die datenschutzrechtlichen Anforderungen (z. B. DSGVO) beruecksichtigt.",
"impl":"Datenschutzrechtliche Anforderungen (DSGVO) werden beruecksichtigt; {{ROLE_DPO}} ist eingebunden."},
{"t":"M","req":"Ein Verzeichnis der Verarbeitungstaetigkeiten wird gefuehrt.",
"impl":"Das Verzeichnis der Verarbeitungstaetigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) gefuehrt."},
{"t":"S","req":"Technische und organisatorische Massnahmen (TOM), Loeschkonzepte und Betroffenenrechte sind geregelt.",
"impl":"TOM, Loeschkonzepte und Prozesse fuer Betroffenenrechte sind geregelt."}]},
])
# ---------------------------------------------------------------------------
# Inline-Bedingungsersetzungen (Feature-Flags in Req/Impl-Text)
# ---------------------------------------------------------------------------
INLINE = {
"{{IF_CUSTOMER}}":"{{#if FLAG_CUSTOMER_SYSTEMS}}, auch fuer Zugriffe in Kundensystemen{{/if}}",
"{{IF_CUSTOMER_IMPL}}":"{{#if FLAG_CUSTOMER_SYSTEMS}}, auch fuer Zugriffe in Kundensystemen{{/if}}",
"{{IF_PKI}}":"{{#if FLAG_CRYPTO_PKI}} und eine PKI/Zertifikatsverwaltung ist etabliert{{/if}}",
"{{IF_PKI_IMPL}}":"{{#if FLAG_CRYPTO_PKI}}; eine PKI/Zertifikatsverwaltung ist etabliert{{/if}}",
"{{IF_OT}}":"", "{{IF_DEV}}":"", "{{IF_CLOUD}}":"", "{{IF_EXTIT}}":"",
}
def inline(s):
for k,v in INLINE.items(): s=s.replace(k,v)
return s
# ---------------------------------------------------------------------------
# Rendering
# ---------------------------------------------------------------------------
META = """# Richtlinie {title}
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{{{ISMS_SCOPE}}}} |
| Organisation | {{{{ORG_NAME}}}} |
| Verantwortlich | {{{{{owner}}}}} |
| Freigabe durch | {{{{ROLE_MANAGEMENT}}}} |
| Version | {{{{DOC_VERSION}}}} |
| Datum | {{{{DOC_DATE}}}} |
| Status | {{{{DOC_STATUS}}}} |
"""
mapping = {"meta":{"paket":"ISMS-Vorlagenpaket v2","standard":"VDA ISA 2027 (Information Security)"},"anforderungen":[]}
def suffix(reqs):
m=s=0; ids=[]
for r in reqs:
if r["t"]=="M": m+=1; ids.append("M%d"%m)
else: s+=1; ids.append("S%d"%s)
return ids
for p in POLICIES:
ids_by_control={}
body=[META.format(title=p["title"], owner=p["owner"])]
body.append("\n## 1. Zweck\n\n"+inline(p["purpose"])+" Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfuellung der Anforderungen des VDA ISA 2027.\n")
body.append("## 2. Geltungsbereich\n\nDiese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).\n")
body.append("## 3. Anforderungen und Umsetzung\n\n> Aufbau je Abschnitt: **Anforderung** (normativ, aus VDA ISA; [MUSS]/[SOLL]) und **Umsetzung bei {{ORG_NAME}}** (tatsaechliche Ausgestaltung, anzupassen wo erforderlich).\n")
sec=0
for c in p["controls"]:
sec+=1
ids=suffix(c["reqs"])
head=f"### 3.{sec} {c['title']} (ISA {c['num']})\n"
wrap_flag=c.get("flag")
block=[head, "\n**Anforderung**\n"]
for r,rid in zip(c["reqs"], ids):
full_id=f"{c['num']}-{rid}"
tag="[MUSS]" if r["t"]=="M" else "[SOLL]"
line=f"<!-- REQ {full_id} -->\n- **{tag}** {inline(r['req'])}"
cond = r.get("cond")
if r["t"]=="S" and not cond: cond="FLAG_INCLUDE_SHOULD"
if cond: line=f"{{{{#if {cond}}}}}\n{line}\n{{{{/if}}}}"
block.append(line)
block.append("\n**Umsetzung bei {{ORG_NAME}}**\n")
for r,rid in zip(c["reqs"], ids):
full_id=f"{c['num']}-{rid}"
line=f"<!-- IMPL {full_id} -->\n{inline(r['impl'])}"
cond = r.get("cond")
if r["t"]=="S" and not cond: cond="FLAG_INCLUDE_SHOULD"
if cond: line=f"{{{{#if {cond}}}}}\n{line}\n{{{{/if}}}}"
block.append(line)
# mapping-Eintrag
mapping["anforderungen"].append({
"id":full_id,"policy":p["id"],"policy_file":p["fn"]+".md",
"control":c["num"],"type":"MUSS" if r["t"]=="M" else "SOLL",
"req_anchor":f"REQ {full_id}","impl_anchor":f"IMPL {full_id}",
"condition": r.get("cond") or (None if r["t"]=="M" else "FLAG_INCLUDE_SHOULD"),
"requirement": inline(r["req"]).replace("{{IF_OT}}","").replace("{{IF_DEV}}","").replace("{{IF_CLOUD}}","").replace("{{IF_EXTIT}}",""),
"implementation": inline(r["impl"]).replace("{{IF_OT}}","").replace("{{IF_DEV}}","").replace("{{IF_CLOUD}}","").replace("{{IF_EXTIT}}",""),
"link":f"{{{{LINK:{p['id']}#{c['num']}}}}}",
"nachweis_link":"{{LINK:NACHWEISREGISTER}}"
})
section_text="\n".join(block)
if wrap_flag:
section_text=f"{{{{#if {wrap_flag}}}}}\n{section_text}\n{{{{/if}}}}"
body.append(section_text+"\n")
# Verbindlichkeit / Rollen / Pruefung / Nachweise / Verwandte
body.append("## 4. Verbindlichkeit\n\nDiese Richtlinie ist fuer alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{"+p["owner"]+"}} ueberwacht.\n")
roles="\n".join("| %s | %s |"%(r,v) for r,v in p["roles"])
body.append("## 5. Rollen und Verantwortlichkeiten\n\n| Rolle | Verantwortung in dieser Richtlinie |\n|-------|-------------------------------------|\n"+roles+"\n")
body.append("## 6. Ueberpruefung und Aktualisierung\n\nDiese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{"+p["owner"]+"}} ueberprueft und durch {{ROLE_MANAGEMENT}} freigegeben.\n")
body.append("## 7. Nachweise\n\nDie Nachweise zur Umsetzung dieser Richtlinie werden nicht in diesem Dokument gefuehrt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehoerigen Eintraegen des ISMS-Tools ({{TOOL_NAME}}).\n")
rel=", ".join("{{LINK:%s}}"%x for x in p["related"])
body.append("## 8. Verwandte Dokumente\n\n- Informationssicherheitsleitlinie: {{LINK:L00}}\n- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}\n- Nachweisregister: {{LINK:NACHWEISREGISTER}}\n- Weitere: "+rel+"\n\n<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool ueber die Hidden-Anker aufgeloest. Im Lesemodus nicht sichtbar. -->\n")
txt="\n".join(body)
with open(os.path.join(RDIR,p["fn"]+".md"),"w",encoding="utf-8") as f:
f.write(txt)
json.dump(mapping, open(os.path.join(BASE,"mapping.json"),"w",encoding="utf-8"), ensure_ascii=False, indent=1)
print("Richtlinien:", len(POLICIES), "| Mapping-Eintraege:", len(mapping["anforderungen"]))
seed/isms-vorlagenpaket-v2/_generate_v3.py
+173
View File
@@ -0,0 +1,173 @@
# -*- coding: utf-8 -*-
"""Generator v3: Richtlinien R01-R14 mit VOLLSTAENDIGEN ISA-Anforderungen
(must/should/high/vhigh, 1:1), Schutzbedarf-Flags, gebuendelte Umsetzung, Mapping, Matrix."""
import os, json, importlib.util, collections
BASE=os.path.dirname(__file__)
RDIR=os.path.join(BASE,"richtlinien")
spec=importlib.util.spec_from_file_location("isa_de", os.path.join(BASE,"_isa_de.py"))
m=importlib.util.module_from_spec(spec); spec.loader.exec_module(m)
DATA=m.DATA; CUSTOM=m.CUSTOM
POLICY_META={
"R01":dict(title="ISMS-Organisation und Rollen", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt Aufbau, Steuerung und Verantwortlichkeiten des ISMS der {{ORG_NAME}} sowie die Berücksichtigung der Informationssicherheit in Projekten.",
roles=[("{{ROLE_MANAGEMENT}}","Beauftragung, Gesamtverantwortung, Managementbewertung"),("{{ROLE_ISB}}","Operative Steuerung des ISMS"),("{{ROLE_IT_LEAD}}","Technische Umsetzung")], related=["L00","R03","R13"]),
"R02":dict(title="Asset- und Klassifizierungsrichtlinie", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt Identifikation, Klassifizierung und geschützten Umgang mit Informationswerten sowie die Zulassung von Hard- und Software.",
roles=[("{{ROLE_IT_LEAD}}","Asset-Inventar, Zulassung Hard-/Software"),("{{ROLE_ISB}}","Klassifizierungsschema"),("Asset Owner","Pflege einzelner Assets")], related=["R01","R08","R11"]),
"R03":dict(title="Risikomanagement- und Auditrichtlinie", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken sowie interne und unabhängige Überprüfungen.",
roles=[("{{ROLE_ISB}}","Risikomanagement, Audits"),("{{ROLE_MANAGEMENT}}","Risikoakzeptanz")], related=["R01","R04"]),
"R04":dict(title="Incident-, Notfall- und Kontinuitätsrichtlinie", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt Meldung und Behandlung von Sicherheitsereignissen, Krisenmanagement sowie Notfall- und Kontinuitätsplanung.",
roles=[("{{ROLE_ISB}}","Vorfallskoordination"),("{{ROLE_IT_LEAD}}","Notfall-/Wiederanlaufplanung"),("{{ROLE_MANAGEMENT}}","Krisenstab")], related=["R03","R10"]),
"R05":dict(title="Personalsicherheit und Awareness", owner="{{ROLE_HR_LEAD}}",
purpose="Diese Richtlinie regelt Eignung, vertragliche Verpflichtung sowie Schulung und Sensibilisierung des Personals.",
roles=[("{{ROLE_HR_LEAD}}","Verpflichtung, Eignung"),("{{ROLE_ISB}}","Awareness/Schulung")], related=["R01","R06"]),
"R06":dict(title="Mobiles Arbeiten und mobile Geräte", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt mobiles Arbeiten sowie den Umgang mit mobilen IT-Geräten und Datenträgern.",
roles=[("{{ROLE_ISB}}","Sicherheitsanforderungen"),("{{ROLE_IT_LEAD}}","Technische Umsetzung")], related=["R05","R07","R08"]),
"R07":dict(title="Physische Sicherheit", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt physischen Schutz durch Sicherheitszonen, Zutrittsschutz und den Umgang mit unterstützenden Betriebsmitteln.",
roles=[("{{ROLE_IT_LEAD}}","Zonen, Zutritt, Betriebsmittel"),("{{ROLE_ISB}}","Vorgaben")], related=["R02","R06"]),
"R08":dict(title="Identitäts- und Zugriffsmanagement", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt Identifikationsmittel, sichere Anmeldung, Kontenverwaltung sowie Vergabe und Kontrolle von Zugriffsrechten.",
roles=[("{{ROLE_IT_LEAD}}","Technische Umsetzung IAM"),("Fachbereiche","Freigabe von Berechtigungen"),("{{ROLE_ISB}}","Überwachung")], related=["R02","R05","R10"]),
"R09":dict(title="Kryptografie- und Übertragungsrichtlinie", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt kryptografische Verfahren, Schlüsselverwaltung und Schutz bei der Informationsübertragung.",
roles=[("{{ROLE_IT_LEAD}}","Verfahren/Schlüssel"),("{{ROLE_ISB}}","Zulässige Algorithmen")], related=["R08","R10","R12"]),
"R10":dict(title="Betriebssicherheit", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt den sicheren IT-Betrieb: Change, Umgebungstrennung, Malware-Schutz, Protokollierung, Schwachstellen, technische Prüfung, Netzwerksicherheit sowie Datensicherung.",
roles=[("{{ROLE_IT_LEAD}}","Sicherer IT-Betrieb"),("{{ROLE_ISB}}","Überwachung")], related=["R04","R08","R11"]),
"R11":dict(title="Sichere Systembeschaffung und Entwicklung", owner="{{ROLE_IT_LEAD}}",
purpose="Diese Richtlinie regelt Informationssicherheit bei Beschaffung und Entwicklung, Anforderungen an Netzdienste sowie Rückgabe und sichere Löschung.",
roles=[("{{ROLE_IT_LEAD}}","Beschaffung/Entwicklung"),("{{ROLE_ISB}}","Sicherheitsanforderungen")], related=["R02","R10","R12"]),
"R12":dict(title="Cloud-, KI- und externe IT-Dienste", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt den Schutz in ausgelagerten/geteilten externen IT-Diensten (Cloud) sowie beim Einsatz von KI-/GenAI-Diensten.",
roles=[("{{ROLE_ISB}}","Freigabe/Steuerung"),("{{ROLE_IT_LEAD}}","Technische Absicherung"),("Fachbereiche","Nutzung freigegebener Dienste")], related=["R09","R11","R13"]),
"R13":dict(title="Lieferanten- und Dienstleistersteuerung", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt Sicherstellung der Informationssicherheit bei Lieferanten, Vertraulichkeitsvereinbarungen und Abgrenzung der Verantwortlichkeiten.",
roles=[("{{ROLE_ISB}}","Lieferantensteuerung"),("Einkauf","Vertragliche Einbindung")], related=["R01","R12"]),
"R14":dict(title="Compliance und Datenschutz", owner="{{ROLE_ISB}}",
purpose="Diese Richtlinie regelt die Einhaltung regulatorischer/vertraglicher Vorgaben sowie den Schutz personenbezogener Daten.",
roles=[("{{ROLE_ISB}}","Compliance-Register"),("{{ROLE_DPO}}","Datenschutz")], related=["L00","R03"]),
}
TAG={"must":"[MUSS]","should":"[SOLL]","high":"[HOCH]","vhigh":"[SEHR HOCH]"}
LETTER={"must":"M","should":"S","high":"H","vhigh":"V"}
COND={"must":None,"should":"FLAG_INCLUDE_SHOULD","high":"FLAG_HIGH_PROTECTION","vhigh":"FLAG_VERY_HIGH_PROTECTION"}
# Reihenfolge der Controls je Policy aus DATA-Insertionsreihenfolge (L00 raus, CUSTOM ans Ende der jeweiligen Policy)
order_by_pol=collections.OrderedDict()
for ctrl,d in DATA.items():
if d["policy"]=="L00": continue
order_by_pol.setdefault(d["policy"],[]).append((ctrl,d,True))
for ctrl,d in CUSTOM.items():
order_by_pol.setdefault(d["policy"],[]).append((ctrl,d,False))
mapping={"meta":{"paket":"ISMS-Vorlagenpaket v2","standard":"VDA ISA 2027 (Information Security)",
"hinweis":"Anforderungen 1:1 aus ISA; Umsetzung gebuendelt je Control. is_isa=false = kundenspezifische Ergaenzung (z.B. KI)."},
"anforderungen":[]}
def render_reqs(ctrl, d):
"""liefert (anforderung_block, impl_block, mapping_entries)"""
entries=[]; lines_req=[];
for lvl in ["must","should","high","vhigh"]:
items=d.get(lvl,[]) or []
cnt=0
for text in items:
cnt+=1
rid=f"{ctrl}-{LETTER[lvl]}{cnt}"
block=f"<!-- REQ {rid} -->\n- **{TAG[lvl]}** {text}"
if COND[lvl]:
block=f"{{{{#if {COND[lvl]}}}}}\n{block}\n{{{{/if}}}}"
lines_req.append(block)
has_elev=bool(d.get("impl_elev"))
impl_anchor = f"IMPL {ctrl}-elev" if (lvl in ("high","vhigh") and has_elev) else f"IMPL {ctrl}"
entries.append({"id":rid,"policy":d["policy"],"control":ctrl,"level":lvl,
"type":{"must":"MUSS","should":"SOLL","high":"HOCH","vhigh":"SEHR HOCH"}[lvl],
"is_isa": ctrl in DATA,
"req_anchor":f"REQ {rid}","impl_anchor":impl_anchor,"condition":COND[lvl],
"requirement":text,
"link":f"{{{{LINK:{d['policy']}#{ctrl}}}}}","nachweis_link":"{{LINK:NACHWEISREGISTER}}"})
# Umsetzung
impl=[f"<!-- IMPL {ctrl} -->\n{d['impl']}"]
if d.get("impl_elev"):
impl.append(f"{{{{#if FLAG_ELEVATED_PROTECTION}}}}\n<!-- IMPL {ctrl}-elev -->\n{d['impl_elev']}\n{{{{/if}}}}")
return "\n".join(lines_req), "\n\n".join(impl), entries
META_HEAD="""# Richtlinie {title}
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{{{ISMS_SCOPE}}}} |
| Organisation | {{{{ORG_NAME}}}} |
| Verantwortlich | {owner} |
| Freigabe durch | {{{{ROLE_MANAGEMENT}}}} |
| Version | {{{{DOC_VERSION}}}} |
| Datum | {{{{DOC_DATE}}}} |
| Status | {{{{DOC_STATUS}}}} |
"""
FN={"R01":"R01_ISMS-Organisation-und-Rollen","R02":"R02_Asset-und-Klassifizierungsrichtlinie",
"R03":"R03_Risikomanagement-und-Auditrichtlinie","R04":"R04_Incident-Notfall-und-Kontinuitaetsrichtlinie",
"R05":"R05_Personalsicherheit-und-Awareness","R06":"R06_Mobiles-Arbeiten-und-mobile-Geraete",
"R07":"R07_Physische-Sicherheit","R08":"R08_Identitaets-und-Zugriffsmanagement",
"R09":"R09_Kryptografie-und-Uebertragungsrichtlinie","R10":"R10_Betriebssicherheit",
"R11":"R11_Sichere-Systembeschaffung-und-Entwicklung","R12":"R12_Cloud-KI-und-externe-IT-Dienste",
"R13":"R13_Lieferanten-und-Dienstleistersteuerung","R14":"R14_Compliance-und-Datenschutz"}
for pol, controls in order_by_pol.items():
meta=POLICY_META[pol]
body=[META_HEAD.format(title=meta["title"], owner=meta["owner"])]
body.append("\n## 1. Zweck\n\n"+meta["purpose"]+" Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.\n")
body.append("## 2. Geltungsbereich\n\nDiese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).\n")
body.append("## 3. Anforderungen und Umsetzung\n\n> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).\n")
sec=0
for ctrl,d,is_isa in controls:
sec+=1
req_block, impl_block, entries=render_reqs(ctrl,d)
mapping["anforderungen"].extend(entries)
isa_label = f"ISA {ctrl}" if is_isa else f"Ergänzung {pol}, nicht ISA"
head=f"### 3.{sec} {d['title']} ({isa_label})\n"
sect = head + "\n**Anforderung**\n\n" + req_block + "\n\n**Umsetzung bei {{ORG_NAME}}**\n\n" + impl_block + "\n"
if d.get("flag"):
sect=f"{{{{#if {d['flag']}}}}}\n{sect}\n{{{{/if}}}}"
body.append(sect)
body.append("## 4. Verbindlichkeit\n\nDiese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch "+meta["owner"]+" überwacht.\n")
roles="\n".join("| %s | %s |"%(r,v) for r,v in meta["roles"])
body.append("## 5. Rollen und Verantwortlichkeiten\n\n| Rolle | Verantwortung in dieser Richtlinie |\n|-------|-------------------------------------|\n"+roles+"\n")
body.append("## 6. Überprüfung und Aktualisierung\n\nDiese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch "+meta["owner"]+" überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.\n")
body.append("## 7. Nachweise\n\nDie Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).\n")
rel=", ".join("{{LINK:%s}}"%x for x in meta["related"])
body.append("## 8. Verwandte Dokumente\n\n- Technische Sicherheits-Baseline: {{LINK:BASELINE}}\n- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}\n- Nachweisregister: {{LINK:NACHWEISREGISTER}}\n- Weitere: "+rel+"\n\n<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->\n")
open(os.path.join(RDIR,FN[pol]+".md"),"w",encoding="utf-8").write("\n".join(body))
# ---- L00 / 1.1.1 Mapping-Eintraege (Leitlinie, kombiniert) ----
d11=DATA["1.1.1"]
for lvl in ["must","should"]:
for i,text in enumerate(d11[lvl],1):
rid=f"1.1.1-{LETTER[lvl]}{i}"
mapping["anforderungen"].insert(0 if lvl=="must" else len(mapping["anforderungen"]), {
"id":rid,"policy":"L00","control":"1.1.1","level":lvl,
"type":{"must":"MUSS","should":"SOLL"}[lvl],"is_isa":True,
"req_anchor":f"REQ {rid}","impl_anchor":f"REQ {rid}","condition":COND[lvl],
"requirement":text,"link":"{{LINK:L00#1.1.1}}","nachweis_link":"{{LINK:NACHWEISREGISTER}}"})
# stabil sortieren nach Control dann Level dann Nummer fuer Lesbarkeit
lvlord={"must":0,"should":1,"high":2,"vhigh":3}
def ctrlkey(c):
base=c.replace("-KI","")
parts=base.split(".")
return tuple(int(p) for p in parts)+ (1 if "-KI" in c else 0,)
mapping["anforderungen"].sort(key=lambda a:(ctrlkey(a["control"]), lvlord[a["level"]], a["id"]))
json.dump(mapping, open(os.path.join(BASE,"mapping.json"),"w",encoding="utf-8"), ensure_ascii=False, indent=1)
cnt=collections.Counter(a["level"] for a in mapping["anforderungen"] if a["is_isa"])
custom=sum(1 for a in mapping["anforderungen"] if not a["is_isa"])
print("Richtlinien R01-R14 neu generiert.")
print("ISA-Anforderungen im Mapping:", dict(cnt), "Summe", sum(cnt.values()))
print("Kundenspezifische (KI) Zusatz:", custom)
seed/isms-vorlagenpaket-v2/_generate_verfahren.py
+295
View File
@@ -0,0 +1,295 @@
# -*- coding: utf-8 -*-
"""Generiert 13 Verfahrensanweisungen (VA-01..VA-13) auditfest:
Zweck, Ausloeser, Eingaben, Ablauf, RACI, Ergebnis/Nachweis, KPI, Verwandte Dokumente.
Erweitert mapping.json um 'verfahren' und annotiert Anforderungen mit erfuellenden Verfahren.
Ergaenzt {{LINK:VA-xx}} in den zugehoerigen Richtlinien."""
import os, json, re
BASE=os.path.dirname(__file__)
VDIR=os.path.join(BASE,"verfahren"); os.makedirs(VDIR, exist_ok=True)
# step = (Text, R, A, C, I)
P=[]
def va(**k): P.append(k)
va(id="VA-01", fn="VA-01_Incident-Response-und-Meldeverfahren", title="Incident-Response- und Meldeverfahren",
owner="{{ROLE_ISB}}", policy="R04", fulfills=["1.6.1-M1","1.6.1-M2","1.6.2-M1","1.6.2-M2","1.6.2-S1","1.6.2-S2"],
purpose="Dieses Verfahren regelt Meldung, Bewertung, Behandlung und Nachbereitung von Informationssicherheitsvorfällen.",
trigger="Meldung eines Sicherheitsereignisses (Mitarbeitende, Technik/Monitoring, Externe) über den definierten Meldeweg.",
inputs=["Meldung/Alarm mit Kurzbeschreibung","Betroffene Systeme/Informationen (Asset-Inventar)","Klassifizierung/Schutzbedarf"],
steps=[
("Ereignis melden: Meldung über {{TOOL_TICKET}} bzw. E-Mail an {{ROLE_ISB}} erfassen.","Meldende Person","{{ROLE_ISB}}","-","-"),
("Triage & Klassifizierung: Relevanz, Schweregrad und Kategorie festlegen.","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","-"),
("Eindämmung: Sofortmaßnahmen zur Begrenzung des Schadens einleiten.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_MANAGEMENT}}"),
("Behebung & Wiederherstellung: Ursache beseitigen, Normalbetrieb herstellen.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-"),
("Meldepflichten prüfen: Kunden/OEM, Behörden, bei personenbezogenen Daten {{ROLE_DPO}} (72-Stunden-Frist).","{{ROLE_ISB}}","{{ROLE_MANAGEMENT}}","{{ROLE_DPO}}","-"),
("Dokumentation & Lessons Learned: Vorfall abschließen, Verbesserungsmaßnahmen ableiten.","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","{{ROLE_MANAGEMENT}}"),
],
output="Dokumentierter, abgeschlossener Vorfall im {{TOOL_TICKET}}; abgeleitete Maßnahmen im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Zeit bis Ersterfassung (Time-to-Detect/Acknowledge)","Zeit bis Behebung (Time-to-Resolve)","Anteil fristgerechter Meldungen"],
related=["R04","VA-02"])
va(id="VA-02", fn="VA-02_IT-Notfall-und-Wiederanlaufverfahren", title="IT-Notfall- und Wiederanlaufverfahren (BCM)",
owner="{{ROLE_IT_LEAD}}", policy="R04", fulfills=["1.6.3-M1","1.6.3-S1","5.2.8-M1","5.2.8-S1"],
purpose="Dieses Verfahren regelt die Aufrechterhaltung und Wiederherstellung kritischer IT-Dienste bei Ausfall oder Krise.",
trigger="Ausfall kritischer IT-Dienste, Notfall oder Krisenfall (Eskalation aus VA-01).",
inputs=["Liste kritischer IT-Dienste mit RTO/RPO","Wiederanlaufpläne","Backup-Status (VA-05)"],
steps=[
("Notfall feststellen & einstufen: Ausmaß bewerten, ggf. Krisenstab einberufen.","{{ROLE_IT_LEAD}}","{{ROLE_MANAGEMENT}}","{{ROLE_ISB}}","-"),
("Kommunikation aktivieren: Interne/externe Stakeholder informieren.","{{ROLE_ISB}}","{{ROLE_MANAGEMENT}}","-","Mitarbeitende"),
("Wiederanlauf priorisieren: Dienste nach RTO/RPO in Reihenfolge bringen.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-"),
("Wiederherstellung durchführen: Systeme/Daten aus Backup (VA-05) wiederherstellen.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Rückkehr zum Normalbetrieb bestätigen & dokumentieren.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","{{ROLE_MANAGEMENT}}"),
("Nachbereitung & Test-Update: Plan aktualisieren, {{BACKUP_TEST_FREQ}} üben.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Wiederhergestellte Dienste; dokumentierter Notfall/Test im ISMS-Tool ({{TOOL_NAME}}); aktualisierte Wiederanlaufpläne.",
kpis=["Einhaltung RTO/RPO","Erfolgsquote Wiederherstellungstests","Aktualität der Notfallpläne"],
related=["R04","VA-01","VA-05"])
va(id="VA-03", fn="VA-03_Berechtigungsverfahren", title="Berechtigungsverfahren (Joiner/Mover/Leaver und Rezertifizierung)",
owner="{{ROLE_IT_LEAD}}", policy="R08", fulfills=["4.1.1-S1","4.1.3-M1","4.2.1-M1","4.2.1-M2","4.2.1-S1"],
purpose="Dieses Verfahren regelt Beantragung, Genehmigung, Änderung, Entzug und regelmäßige Überprüfung von Zugriffsrechten.",
trigger="Eintritt, Rollenwechsel oder Austritt einer Person; Berechtigungsantrag; fällige Rezertifizierung.",
inputs=["Personalmeldung (HR)","Rollen-/Rechtekatalog (RBAC)","Bestehende Berechtigungen aus {{TOOL_IAM}}"],
steps=[
("Antrag erfassen: Zugang/Recht im {{TOOL_TICKET}} beantragen (Joiner/Mover).","Vorgesetzte/Fachbereich","{{ROLE_IT_LEAD}}","-","-"),
("Fachliche Genehmigung: Erforderlichkeit nach Minimalprinzip prüfen und freigeben.","Fachbereich/Dateneigentümer","Fachbereich/Dateneigentümer","{{ROLE_ISB}}","-"),
("Umsetzung: Rechte rollenbasiert in {{TOOL_IAM}} setzen.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","Antragsteller"),
("Leaver/Änderung: Bei Austritt/Wechsel Rechte unverzüglich entziehen/anpassen.","{{ROLE_IT_LEAD}}","{{ROLE_HR_LEAD}}","-","-"),
("Rezertifizierung ({{RECERT_FREQ}}, BL-IAM-05): Owner bestätigen/entziehen Rechte.","Fachbereich/Dateneigentümer","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","-"),
("Privilegierte Konten: gesondert prüfen und protokollieren (BL-IAM-06).","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Dokumentierte Anträge/Genehmigungen im {{TOOL_TICKET}}; aktueller Berechtigungsstand in {{TOOL_IAM}}; Rezertifizierungsnachweis.",
kpis=["Anteil fristgerecht entzogener Leaver-Rechte","Rezertifizierungsquote","Zahl verwaister/privilegierter Konten"],
related=["R08","VA-01"])
va(id="VA-04", fn="VA-04_Change-und-Patch-Management-Verfahren", title="Change- und Patch-Management-Verfahren",
owner="{{ROLE_IT_LEAD}}", policy="R10", fulfills=["5.2.1-M1","5.2.5-M1"],
purpose="Dieses Verfahren regelt geplante Änderungen an IT-Systemen sowie das risikoorientierte Einspielen von Patches.",
trigger="Änderungsbedarf, verfügbarer Patch oder identifizierte Schwachstelle (VA-06).",
inputs=["Change-/Patch-Antrag","Risikoeinschätzung","Patch-SLA (BL-OPS-01)"],
steps=[
("Change beantragen & klassifizieren (Standard/Normal/Notfall) im {{TOOL_TICKET}}.","Antragsteller","{{ROLE_IT_LEAD}}","-","-"),
("Risiko-/Auswirkungsbewertung inkl. Rollback-Plan.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-"),
("Genehmigung durch CAB/verantwortliche Rolle.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-"),
("Test in getrennter Umgebung (BL-OPS, R10).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Umsetzung in Produktion gemäß Patch-SLA (kritisch {{PATCH_SLA_CRIT}}).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","Betroffene"),
("Verifikation & Dokumentation des Ergebnisses im {{TOOL_TICKET}}.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Dokumentierte, genehmigte und verifizierte Änderung/Patch im {{TOOL_TICKET}}.",
kpis=["Patch-Compliance je Kritikalität","Anteil erfolgreicher Changes (ohne Rollback)","Durchlaufzeit kritischer Patches"],
related=["R10","VA-06"])
va(id="VA-05", fn="VA-05_Backup-und-Restore-Verfahren", title="Backup- und Restore-Verfahren",
owner="{{ROLE_IT_LEAD}}", policy="R10", fulfills=["5.2.9-M1","5.2.9-M2","5.2.9-S1"],
purpose="Dieses Verfahren regelt Datensicherung, Aufbewahrung und Wiederherstellung nach dem {{BACKUP_SCHEME}}-Schema.",
trigger="Regulärer Sicherungslauf; Wiederherstellungsbedarf; geplanter Restore-Test.",
inputs=["Sicherungsplan je System","Klassifizierung/RPO","Backup-Ziele ({{TECH_BACKUP}})"],
steps=[
("Sicherung durchführen: automatisierte Backups gemäß {{BACKUP_SCHEME}} (BL-OPS-05).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Überwachung: Erfolg/Fehler prüfen, Fehlläufe nachverfolgen ({{TOOL_TICKET}}).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Schutz & Auslagerung: 1 Kopie offline/immutable, Aufbewahrung {{BACKUP_RETENTION}}.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Restore-Anforderung bearbeiten (bei Bedarf/Notfall, VA-02).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","Anforderer","-"),
("Wiederherstellungstest ({{BACKUP_TEST_FREQ}}, BL-OPS-06) durchführen & dokumentieren.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Protokollierte Sicherungen; dokumentierte Restore-Tests; Nachweis im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Backup-Erfolgsquote","Erfolgsquote Restore-Tests","Einhaltung RPO"],
related=["R10","VA-02"])
va(id="VA-06", fn="VA-06_Schwachstellenmanagement-Verfahren", title="Schwachstellenmanagement-Verfahren",
owner="{{ROLE_IT_LEAD}}", policy="R10", fulfills=["5.2.5-M1","5.2.5-S1","5.2.6-M1"],
purpose="Dieses Verfahren regelt Erkennung, Bewertung, Behandlung und technische Prüfung von Schwachstellen.",
trigger="Regelmäßiger Scan ({{VULN_SCAN_FREQ}}), Sicherheitsmeldung/CVE, Penetrationstest ({{PENTEST_FREQ}}).",
inputs=["Scan-/Testberichte","Asset-Inventar & Kritikalität","Patch-SLA (BL-OPS-01)"],
steps=[
("Identifikation: Schwachstellen-Scan {{VULN_SCAN_FREQ}} (BL-OPS-02) und Meldungen auswerten.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Bewertung & Priorisierung nach Kritikalität und Exponierung.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Behandlung anstoßen: Patch/Change (VA-04) oder kompensierende Maßnahme.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-"),
("Technische Prüfung: Härtung (BL-OPS-07) und Penetrationstests ({{PENTEST_FREQ}}, BL-OPS-08).","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","Externer Dienstleister","-"),
("Nachverfolgung & Verifikation der Behebung im {{TOOL_TICKET}}.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Nachverfolgte Schwachstellen mit Behandlungsstatus im {{TOOL_TICKET}}; Testberichte.",
kpis=["Mittlere Behebungszeit je Kritikalität","Offene kritische Schwachstellen","Scan-Abdeckung"],
related=["R10","VA-04"])
va(id="VA-07", fn="VA-07_Kryptokonzept-und-Schluesselverwaltung", title="Kryptokonzept und Schlüsselverwaltung",
owner="{{ROLE_IT_LEAD}}", policy="R09", fulfills=["5.1.1-M1","5.1.1-S1","5.1.2-M1","5.1.2-S1"],
purpose="Dieses Verfahren regelt den Einsatz kryptografischer Verfahren und die Verwaltung von Schlüsseln über den Lebenszyklus.",
trigger="Neuer Bedarf an Verschlüsselung/Zertifikaten; Schlüsselerneuerung/-sperrung; Änderung des Stands der Technik.",
inputs=["Zulässige Algorithmen (BL-CRY-02)","Schutzbedarf der Daten","Zertifikats-/Schlüsselbestand"],
steps=[
("Bedarf & Verfahren festlegen: zulässige Algorithmen {{CRYPTO_ALGO}} (BL-CRY-02) wählen.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Schlüssel/Zertifikate erzeugen und sicher verteilen (BL-CRY-05).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Speicherung & Zugriffsschutz (getrennte Aufbewahrung, {{#if FLAG_CRYPTO_PKI}}PKI, {{/if}}Berechtigungen).","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Übertragungsschutz sicherstellen: mindestens {{TLS_MIN}} (BL-CRY-01).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Erneuerung/Sperrung/Vernichtung dokumentieren.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Dokumentiertes Kryptokonzept; nachvollziehbarer Schlüssel-/Zertifikatslebenszyklus.",
kpis=["Anteil konformer Verfahren/Algorithmen","Ablaufende Zertifikate ohne Erneuerung","Abdeckung Transportverschlüsselung"],
related=["R09","VA-04"])
va(id="VA-08", fn="VA-08_Asset-und-Klassifizierungsverfahren", title="Asset- und Klassifizierungsverfahren",
owner="{{ROLE_IT_LEAD}}", policy="R02", fulfills=["1.3.1-M1","1.3.1-M2","1.3.1-S1","1.3.2-M1","1.3.2-M2","1.3.2-S1"],
purpose="Dieses Verfahren regelt Erfassung, Owner-Zuordnung, Klassifizierung und Pflege von Informationswerten und Assets.",
trigger="Neues/geändertes Asset; Beschaffung; regelmäßige Inventurprüfung.",
inputs=["Beschaffungs-/Änderungsmeldung","Klassifizierungsschema","Asset-Inventar ({{TOOL_NAME}})"],
steps=[
("Asset erfassen im Inventar ({{TOOL_NAME}}) mit Attributen.","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Owner zuordnen.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","Asset Owner"),
("Klassifizieren (Vertraulichkeit/Integrität/Verfügbarkeit) durch Owner.","Asset Owner","Asset Owner","{{ROLE_ISB}}","-"),
("Handhabungsvorgaben je Schutzklasse anwenden (Kennzeichnung/Speicherung/Löschung BL-DEL-01).","Asset Owner","{{ROLE_ISB}}","-","Mitarbeitende"),
("Pflege & Review ({{REVIEW_CYCLE}}) auf Aktualität.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Aktuelles, klassifiziertes Asset-Inventar im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Inventar-Abdeckung","Anteil klassifizierter Assets","Assets ohne Owner"],
related=["R02","VA-03"])
va(id="VA-09", fn="VA-09_Risikomanagement-Verfahren", title="Risikomanagement-Verfahren",
owner="{{ROLE_ISB}}", policy="R03", fulfills=["1.4.1-M1","1.4.1-M2","1.4.1-M3","1.4.1-S1"],
purpose="Dieses Verfahren regelt Identifikation, Analyse, Bewertung, Behandlung und Überwachung von Informationssicherheitsrisiken.",
trigger="Neues System/Projekt, Vorfall, Änderung, regelmäßiger Review-Zyklus.",
inputs=["Asset-/Prozessliste","Bewertungsskalen & Akzeptanzschwellen","Bestehendes Risikoregister"],
steps=[
("Risiken identifizieren (Assets, Bedrohungen, Schwachstellen).","{{ROLE_ISB}}","{{ROLE_ISB}}","Asset/Prozessverantwortliche","-"),
("Analysieren & bewerten (Eintritt × Schadenshöhe) im ISMS-Tool ({{TOOL_NAME}}).","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","-"),
("Behandlung festlegen (reduzieren/vermeiden/übertragen/akzeptieren) und Maßnahmen planen.","{{ROLE_ISB}}","{{ROLE_MANAGEMENT}}","Fachbereich","-"),
("Restrisiko-Akzeptanz dokumentieren.","{{ROLE_MANAGEMENT}}","{{ROLE_MANAGEMENT}}","{{ROLE_ISB}}","-"),
("Überwachen & aktualisieren ({{REVIEW_CYCLE}} und anlassbezogen).","{{ROLE_ISB}}","{{ROLE_ISB}}","-","-"),
],
output="Gepflegtes Risikoregister mit Behandlungsplan und Akzeptanzentscheidungen im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Anteil behandelter Risiken","Überfällige Maßnahmen","Aktualität des Risikoregisters"],
related=["R03","VA-01"])
va(id="VA-10", fn="VA-10_Lieferanten-Onboarding-und-Bewertung", title="Lieferanten-Onboarding- und Bewertungsverfahren",
owner="{{ROLE_ISB}}", policy="R13", fulfills=["6.1.1-M1","6.1.1-M2","6.1.1-S1","6.1.2-M1","6.1.2-S1","6.1.3-M1"],
purpose="Dieses Verfahren regelt Auswahl, sicherheitsbezogene Bewertung, vertragliche Bindung und Überwachung von Lieferanten/Dienstleistern.",
trigger="Neuer Lieferant/Dienstleister mit Zugriff auf Informationen; Vertragsverlängerung; periodische Überprüfung.",
inputs=["Leistungs-/Schutzbedarfsbeschreibung","Risikoklassen (BL-SUP-01)","NDA-/Vertragsvorlagen"],
steps=[
("Bedarf & Risikoklasse bestimmen (Schutzbedarf, Zugriff).","Einkauf/Fachbereich","{{ROLE_ISB}}","-","-"),
("Sicherheitsbewertung (Selbstauskunft/Nachweise/TISAX) durchführen.","{{ROLE_ISB}}","{{ROLE_ISB}}","Fachbereich","-"),
("NDA & vertragliche Sicherheitsanforderungen vereinbaren.","Einkauf","{{ROLE_MANAGEMENT}}","{{ROLE_ISB}}","-"),
("Verantwortlichkeiten abgrenzen (Betrieb/Sicherheit/Meldung).","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","-"),
("Ins Lieferantenverzeichnis ({{TOOL_NAME}}) aufnehmen und {{REVIEW_CYCLE}} überprüfen.","{{ROLE_ISB}}","{{ROLE_ISB}}","-","-"),
],
output="Bewerteter, vertraglich gebundener Lieferant im Lieferantenverzeichnis ({{TOOL_NAME}}); NDA hinterlegt.",
kpis=["Anteil bewerteter Lieferanten","NDA-Abdeckung","Überfällige Lieferantenprüfungen"],
related=["R13","VA-11"])
va(id="VA-11", fn="VA-11_Cloud-und-KI-Freigabeverfahren", title="Cloud- und KI-Freigabeverfahren",
owner="{{ROLE_ISB}}", policy="R12", fulfills=["5.3.4-M1","5.3.4-S1","5.3.4-KI-M1","5.3.4-KI-M2","5.3.4-KI-M3","5.3.4-KI-S1"],
purpose="Dieses Verfahren regelt Bewertung und Freigabe von Cloud- und KI-/GenAI-Diensten sowie die zulässige Nutzung.",
trigger="Antrag zur Nutzung eines Cloud- oder KI-Dienstes.",
inputs=["Dienstbeschreibung & Anbieterinfos","Schutzbedarf/Datenklassen","Vertrags-/DPA-Unterlagen"],
steps=[
("Antrag erfassen im {{TOOL_TICKET}} (Dienst, Zweck, Datenklassen).","Antragsteller/Fachbereich","{{ROLE_ISB}}","-","-"),
("Bewertung: Schutzbedarf, Datenlokation/EU, Mandantentrennung, Exit; bei KI Trainings-/Weitergabe-Ausschluss.","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","{{ROLE_DPO}}"),
("Vertrag/DPA prüfen (bei KI: Opt-out/Enterprise-Vertrag, EU AI Act).","{{ROLE_ISB}}","{{ROLE_MANAGEMENT}}","{{ROLE_DPO}}","-"),
("Freigabe & Aufnahme in die Freigabeliste ({{TOOL_NAME}}); zulässige Datenklassen festlegen.","{{ROLE_ISB}}","{{ROLE_ISB}}","-","Fachbereich"),
("Nutzung & Kontrolle: Human-in-the-Loop bei KI, periodische Überprüfung ({{REVIEW_CYCLE}}).","Fachbereich","{{ROLE_ISB}}","-","-"),
],
output="Freigabeentscheidung und Freigabeliste im ISMS-Tool ({{TOOL_NAME}}); dokumentierte zulässige Datenklassen.",
kpis=["Anteil freigegebener vs. genutzter Dienste","Schatten-IT-Funde","Überfällige Dienst-Reviews"],
related=["R12","VA-10"])
va(id="VA-12", fn="VA-12_Awareness-und-Schulungsverfahren", title="Awareness- und Schulungsverfahren",
owner="{{ROLE_ISB}}", policy="R05", fulfills=["2.1.3-M1","2.1.3-S1"],
purpose="Dieses Verfahren regelt Planung, Durchführung und Nachweis von Sensibilisierung und Schulung zur Informationssicherheit.",
trigger="Eintritt neuer Mitarbeitender; jährlicher Schulungszyklus; anlassbezogen nach Vorfällen.",
inputs=["Schulungsplan/Curriculum (BL-HR-01)","Zielgruppen/Rollen","Teilnahmestatus ({{TOOL_NAME}})"],
steps=[
("Schulungsbedarf & Zielgruppen planen (rollenspezifisch).","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_HR_LEAD}}","-"),
("Onboarding-Schulung bei Eintritt durchführen.","{{ROLE_HR_LEAD}}","{{ROLE_ISB}}","-","Mitarbeitende"),
("Regelmäßige Schulung ({{REVIEW_CYCLE}}, BL-HR-01) durchführen.","{{ROLE_ISB}}","{{ROLE_ISB}}","-","Mitarbeitende"),
("Wirksamkeit prüfen (Phishing-Simulation) und nachschulen.","{{ROLE_ISB}}","{{ROLE_ISB}}","{{ROLE_IT_LEAD}}","-"),
("Teilnahme nachweisen im ISMS-Tool ({{TOOL_NAME}}).","{{ROLE_HR_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Dokumentierte Schulungsteilnahme und Wirksamkeitsmessung im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Schulungsquote","Phishing-Klickrate","Anteil rollenspezifischer Schulungen"],
related=["R05","VA-01"])
va(id="VA-13", fn="VA-13_Logging-und-Monitoring-Verfahren", title="Logging- und Monitoring-Verfahren",
owner="{{ROLE_IT_LEAD}}", policy="R10", fulfills=["5.2.4-M1","5.2.4-S1"],
purpose="Dieses Verfahren regelt Erhebung, Schutz, Auswertung und Aufbewahrung sicherheitsrelevanter Protokolldaten.",
trigger="Kontinuierlicher Betrieb; sicherheitsrelevantes Ereignis; Alarm aus {{TECH_SIEM}}.",
inputs=["Log-Quellen/Systeme","Aufbewahrungsvorgaben (BL-OPS-04)","Alarmierungsregeln"],
steps=[
("Log-Quellen anbinden und zentral in {{TECH_SIEM}} erfassen (BL-OPS-04).","{{ROLE_IT_LEAD}}","{{ROLE_IT_LEAD}}","-","-"),
("Manipulationsschutz & Aufbewahrung {{LOG_RETENTION}} sicherstellen.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Auswertung & Alarmierung: Regeln pflegen, Auffälligkeiten prüfen.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Verdachtsfall an Incident-Response (VA-01) übergeben.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
("Regelmäßige Überprüfung der Abdeckung und Regeln.","{{ROLE_IT_LEAD}}","{{ROLE_ISB}}","-","-"),
],
output="Zentrale, geschützte Protokollierung mit Auswertung; Nachweis im ISMS-Tool ({{TOOL_NAME}}).",
kpis=["Log-Quellen-Abdeckung","Mittlere Zeit bis Alarmreaktion","Anteil auswertbarer Ereignisse"],
related=["R10","VA-01"])
# ---------- Rendering ----------
def render(p):
L=[]
L.append(f"# {p['title']}\n")
L.append("| Dokumenteninformation | Wert |")
L.append("|-----------------------|------|")
L.append(f"| Dokumententyp | Verfahrensanweisung ({p['id']}) |")
L.append("| Geltungsbereich | {{ISMS_SCOPE}} |")
L.append("| Organisation | {{ORG_NAME}} |")
L.append(f"| Prozessverantwortlich | {p['owner']} |")
L.append("| Freigabe durch | {{ROLE_ISB}} |")
L.append("| Version | {{DOC_VERSION}} |")
L.append("| Datum | {{DOC_DATE}} |")
L.append("| Status | {{DOC_STATUS}} |")
L.append(f"\n<!-- FULFILLS {', '.join(p['fulfills'])} | POLICY {p['policy']} -->\n")
L.append("## 1. Zweck\n\n"+p["purpose"]+f" Es operationalisiert die zugehörige Richtlinie ({{{{LINK:{p['policy']}}}}}).\n")
L.append("## 2. Geltungsbereich\n\nGilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).\n")
L.append("## 3. Auslöser\n\n"+p["trigger"]+"\n")
L.append("## 4. Eingaben\n\n"+"\n".join("- "+i for i in p["inputs"])+"\n")
L.append("## 5. Ablauf\n")
for n,s in enumerate(p["steps"],1):
L.append(f"{n}. {s[0]}")
L.append("\n## 6. RACI\n")
L.append("| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |")
L.append("|---|---------|------------------|------------------|-----------------|----------------|")
for n,s in enumerate(p["steps"],1):
short=s[0].split(":")[0] if ":" in s[0] else s[0][:40]
L.append(f"| {n} | {short} | {s[1]} | {s[2]} | {s[3]} | {s[4]} |")
L.append("\n## 7. Ergebnis & Nachweis\n\n"+p["output"]+" Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.\n")
L.append("## 8. Kennzahlen (KPI)\n\n"+"\n".join("- "+k for k in p["kpis"])+"\n")
L.append("## 9. Verwandte Dokumente\n")
rel="\n".join("- "+("Zugehörige Richtlinie: " if x==p['policy'] else "")+f"{{{{LINK:{x}}}}}" for x in p["related"])
L.append(rel)
L.append("- Technische Sicherheits-Baseline: {{LINK:BASELINE}}")
L.append("- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}")
L.append("\n<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->\n")
return "\n".join(L)
for p in P:
open(os.path.join(VDIR,p["fn"]+".md"),"w",encoding="utf-8").write(render(p))
# ---------- mapping.json erweitern ----------
mp=os.path.join(BASE,"mapping.json")
d=json.load(open(mp,encoding="utf-8"))
d["verfahren"]=[{"id":p["id"],"title":p["title"],"file":"verfahren/"+p["fn"]+".md",
"policy":p["policy"],"fulfills":p["fulfills"],"link":"{{LINK:%s}}"%p["id"]} for p in P]
# Annotation je Anforderung
by_req={}
for p in P:
for rid in p["fulfills"]: by_req.setdefault(rid,[]).append(p["id"])
for a in d["anforderungen"]:
a["verfahren"]=by_req.get(a["id"],[])
json.dump(d,open(mp,"w",encoding="utf-8"),ensure_ascii=False,indent=1)
# ---------- {{LINK:VA-xx}} in Richtlinien ergaenzen ----------
pol2va={}
for p in P: pol2va.setdefault(p["policy"],[]).append(p["id"])
for fp in [os.path.join(BASE,"richtlinien",f) for f in os.listdir(os.path.join(BASE,"richtlinien"))]:
pid=os.path.basename(fp).split("_")[0]
if pid in pol2va:
txt=open(fp,encoding="utf-8").read()
line="- Zugehörige Verfahren: "+", ".join("{{LINK:%s}}"%v for v in pol2va[pid])
if "Zugehörige Verfahren" not in txt and "- Technische Sicherheits-Baseline: {{LINK:BASELINE}}" in txt:
txt=txt.replace("- Technische Sicherheits-Baseline: {{LINK:BASELINE}}",
line+"\n- Technische Sicherheits-Baseline: {{LINK:BASELINE}}")
open(fp,"w",encoding="utf-8").write(txt)
print("Verfahren erstellt:",len(P))
print("Anforderungen mit Verfahren:",sum(1 for a in d["anforderungen"] if a["verfahren"]))
print("Policies mit Verfahrenslink:",sorted(pol2va))
seed/isms-vorlagenpaket-v2/_isa_de.py
+656
View File
@@ -0,0 +1,656 @@
# -*- coding: utf-8 -*-
# Faithful deutsche 1:1-Uebernahme aller ISA-2027-Anforderungen (Information Security)
# je Control: must / should / high / vhigh (Reihenfolge = ISA-Reihenfolge).
# 'impl' = gebuendelte auditfeste Umsetzung (Normalniveau), 'impl_elev' = Ergaenzung bei hohem/sehr hohem Schutzbedarf.
DATA = {}
DATA["1.1.1"] = dict(policy="L00", title="Informationssicherheitsrichtlinien",
must=[
"Die Anforderungen der Informationssicherheit sind bestimmt, dokumentiert und an den Zielen der Organisation ausgerichtet.",
"Eine Leitlinie existiert und ist durch die Leitung der Organisation genehmigt.",
"Die Leitlinie benennt Ziele und die Bedeutung der Informationssicherheit innerhalb der Organisation.",
"Die Leitlinien werden den Beschäftigten in geeigneter Form zur Verfügung gestellt (z. B. Intranet).",
"Beschäftigte und externe Geschäftspartner werden über für sie relevante Änderungen informiert.",
], should=[
"Die Informationssicherheitsanforderungen basieren auf der Strategie der Organisation; Gesetze und Verträge werden in der Leitlinie berücksichtigt.",
"Die Leitlinie benennt Konsequenzen bei Nichteinhaltung.",
"Weitere relevante Sicherheitsrichtlinien sind etabliert.",
"Regelmäßige Überprüfung und ggf. Überarbeitung der Richtlinien sind etabliert.",
], high=[], vhigh=[],
impl="") # L00 ist die Leitlinie selbst; Umsetzung ist der Leitlinientext (kombiniertes Dokument).
DATA["1.2.1"] = dict(policy="R01", title="Steuerung der Informationssicherheit",
must=[
"Der Geltungsbereich des ISMS (die durch das ISMS gesteuerte Organisation) ist definiert.",
"Die Anforderungen der Organisation an das ISMS sind bestimmt.",
"Die Organisationsleitung hat das ISMS beauftragt und genehmigt.",
"Das ISMS stellt der Organisationsleitung geeignete Mittel zur Überwachung und Steuerung bereit (z. B. Managementbewertung).",
"Die anwendbaren Controls sind bestimmt (z. B. ISO-27001-Anwendbarkeitserklärung oder ausgefüllter ISA-Katalog).",
"Die Wirksamkeit des ISMS wird regelmäßig durch die Leitung überprüft.",
], should=[], high=[], vhigh=[],
impl="Der ISMS-Geltungsbereich, die Anforderungen und die anwendbaren Controls (Anwendbarkeitserklärung/ISA-Katalog) sind im ISMS-Tool ({{TOOL_NAME}}) dokumentiert. Die {{ROLE_MANAGEMENT}} hat das ISMS per Managementbeschluss beauftragt und genehmigt, stellt Ressourcen bereit und überprüft die Wirksamkeit mindestens {{REVIEW_CYCLE}} in einer dokumentierten Managementbewertung; die operative Steuerung liegt bei {{ROLE_ISB}}.")
DATA["1.2.2"] = dict(policy="R01", title="Organisation der Informationssicherheit",
must=[
"Verantwortlichkeiten für Informationssicherheit sind definiert, dokumentiert und zugewiesen.",
"Die verantwortlichen Beschäftigten sind definiert, qualifiziert und für ihre Aufgabe befähigt.",
"Die erforderlichen Ressourcen stehen zur Verfügung.",
"Die Ansprechpartner sind innerhalb der Organisation und relevanten Geschäftspartnern bekannt.",
], should=[
"Es besteht eine Definition und Dokumentation einer angemessenen Informationssicherheitsstruktur innerhalb der Organisation.",
"Sicherheitsrelevante Rollen, die nicht Teil des ISMS, aber für die Informationssicherheit relevant sind, werden berücksichtigt.",
], high=[
"Eine angemessene organisatorische Trennung von Verantwortlichkeiten ist etabliert, um Interessenkonflikte zu vermeiden (Funktionstrennung). (C, I, A)",
], vhigh=[],
impl="Die Verantwortlichkeiten sind in der Rollen-/Verantwortungsmatrix und im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und den Rolleninhabern sowie relevanten Geschäftspartnern bekannt gemacht. Die Rolle {{ROLE_ISB}} ist benannt, qualifiziert, mit Ressourcen und Weisungsrechten ausgestattet und berichtet direkt an die {{ROLE_MANAGEMENT}}.",
impl_elev="Bei hohem Schutzbedarf ist eine organisatorische Funktionstrennung (z. B. Umsetzung vs. Kontrolle) etabliert; unvermeidbare Doppelrollen werden durch kompensierende Kontrollen (Vier-Augen-Prinzip) abgesichert.")
DATA["1.2.3"] = dict(policy="R01", title="Informationssicherheit in Projekten",
must=[
"Projekte werden unter Berücksichtigung der Informationssicherheitsanforderungen klassifiziert.",
], should=[
"Verfahren und Kriterien für die Klassifizierung von Projekten sind dokumentiert.",
"In einer frühen Projektphase wird eine Risikobewertung nach dem definierten Verfahren durchgeführt und bei Projektänderungen wiederholt.",
"Für identifizierte Informationssicherheitsrisiken werden Maßnahmen abgeleitet und im Projekt berücksichtigt.",
], high=[
"Die abgeleiteten Maßnahmen werden während des Projekts regelmäßig überprüft und bei Änderungen der Bewertungskriterien neu bewertet. (C, I, A)",
], vhigh=[],
impl="Projekte werden zu Beginn anhand eines dokumentierten Kriterienkatalogs hinsichtlich Informationssicherheitsbedarf klassifiziert; die Einstufung wird im {{TOOL_TICKET}} bzw. ISMS-Tool dokumentiert. In einer frühen Phase und bei Änderungen erfolgt eine Risikobewertung; abgeleitete Maßnahmen werden als Aufgaben im {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft; bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden.",
impl_elev="Bei hohem Schutzbedarf werden die abgeleiteten Maßnahmen fortlaufend im Projektverlauf überprüft und bei geänderten Bewertungskriterien neu bewertet.")
DATA["1.3.1"] = dict(policy="R02", title="Identifikation von Informationswerten",
must=[
"Informationswerte und weitere sicherheitsrelevante Assets der Organisation sind identifiziert und erfasst.",
"Die unterstützenden Assets, die die Informationswerte verarbeiten, sind identifiziert und erfasst.",
], should=[
"Ein Katalog der relevanten Informationswerte existiert; dabei werden die einschlägigen Aspekte berücksichtigt.",
], high=[], vhigh=[],
impl="Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt; Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.")
DATA["1.3.2"] = dict(policy="R02", title="Klassifizierung von Informationswerten",
must=[
"Ein konsistentes Schema zur Klassifizierung von Informationswerten hinsichtlich des Schutzziels Vertraulichkeit ist vorhanden.",
"Die Bewertung der identifizierten Informationswerte erfolgt nach den definierten Kriterien und wird dem Klassifizierungsschema zugeordnet.",
"Vorgaben zur Handhabung unterstützender Assets (z. B. Kennzeichnung, Nutzung, Transport, Speicherung, Rückgabe, Löschung/Vernichtung) abhängig von der Klassifizierung sind vorhanden und umgesetzt.",
], should=[
"Die Schutzziele Integrität und Verfügbarkeit werden berücksichtigt.",
], high=[], vhigh=[],
impl="Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht.")
DATA["1.3.3"] = dict(policy="R02", title="Nutzung freigegebener externer IT-Dienste/Hardware",
must=[
"Externe IT-Dienste werden nicht ohne ausdrückliche Bewertung und Umsetzung der Informationssicherheitsanforderungen genutzt; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Die externen IT-Dienste sind mit dem Schutzbedarf der verarbeiteten Informationswerte abgestimmt.",
], should=[
"Anforderungen an Beschaffung, Inbetriebnahme und Freigabe im Zusammenhang mit der Nutzung externer IT-Dienste sind bestimmt und erfüllt.",
"Ein Verfahren zur Freigabe unter Berücksichtigung des Schutzbedarfs ist etabliert.",
"Externe IT-Dienste und ihre Freigabe sind dokumentiert.",
"Es wird regelmäßig überprüft, dass nur freigegebene externe IT-Dienste genutzt werden.",
], high=[], vhigh=[],
impl="Externe IT-Dienste/-Komponenten werden vor Nutzung bewertet, mit dem Schutzbedarf abgestimmt und über ein definiertes Verfahren freigegeben; eine Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt und regelmäßig auf ausschließliche Nutzung freigegebener Dienste geprüft.")
DATA["1.3.4"] = dict(policy="R02", title="Freigabe von Software",
must=[
"Software wird vor Installation oder Nutzung freigegeben; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Die Softwarefreigabe gilt auch für Spezialsoftware wie Wartungswerkzeuge.",
], should=[
"Die zu verwaltenden Softwarearten (Firmware, Betriebssysteme, Anwendungen, Bibliotheken, Gerätetreiber) sind bestimmt.",
"Repositorys der verwalteten Software existieren.",
"Die Software-Repositorys sind gegen unbefugte Manipulation geschützt.",
"Die Freigabe von Software wird regelmäßig überprüft.",
"Softwareversionen und Patch-Stände sind bekannt.",
], high=[], vhigh=[
"Zusätzliche Anforderungen an die Softwarenutzung (z. B. Kontroll-/Überwachungsbedarf der Nutzung) sind, sofern vorhanden, bestimmt. (C, I, A)",
],
impl="Software (inkl. Spezial-/Wartungssoftware) wird vor Einsatz freigegeben; eine Liste zugelassener Software (Whitelist) mit bekannten Versionen/Patch-Ständen wird im ISMS-Tool gepflegt, Beschaffung/Freigabe läuft über {{TOOL_TICKET}}. Verwaltete Softwarearten sind bestimmt, Repositorys gegen Manipulation geschützt und Freigaben werden regelmäßig überprüft.",
impl_elev="Bei sehr hohem Schutzbedarf sind zusätzliche Kontroll-/Überwachungsanforderungen an die Softwarenutzung bestimmt und umgesetzt.")
DATA["1.4.1"] = dict(policy="R03", title="Risikomanagement",
must=[
"Risikobewertungen werden regelmäßig und anlassbezogen durchgeführt.",
"Informationssicherheitsrisiken werden angemessen bewertet (z. B. Eintrittswahrscheinlichkeit und mögliches Schadensausmaß).",
"Informationssicherheitsrisiken werden dokumentiert.",
"Jedem Informationssicherheitsrisiko ist ein Verantwortlicher (Risk Owner) zugeordnet, der für Bewertung und Behandlung verantwortlich ist.",
], should=[
"Ein Verfahren zur Identifikation, Bewertung und Behandlung von Sicherheitsrisiken ist vorhanden.",
"Kriterien für Bewertung und Behandlung von Sicherheitsrisiken existieren.",
"Maßnahmen zur Risikobehandlung und ihre Verantwortlichen sind festgelegt und dokumentiert; ein Maßnahmenplan bzw. eine Umsetzungsübersicht wird nachverfolgt.",
"Bei Änderungen des Umfelds (z. B. Organisationsstruktur, Standort, Regularien) erfolgt zeitnah eine Neubewertung.",
], high=[], vhigh=[],
impl="Das dokumentierte Risikomanagement-Verfahren mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.")
DATA["1.5.1"] = dict(policy="R03", title="Prüfung der Einhaltung im IS-Betrieb",
must=[
"Die Einhaltung der Richtlinien wird organisationsweit überprüft.",
"Informationssicherheitsrichtlinien und -verfahren werden regelmäßig überprüft.",
"Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.",
"Die Einhaltung von Informationssicherheitsanforderungen (z. B. technische Vorgaben) wird regelmäßig überprüft.",
"Die Ergebnisse der durchgeführten Überprüfungen werden aufgezeichnet und aufbewahrt.",
], should=[
"Ein Plan für Inhalt und Rahmenbedingungen (Zeitplan, Umfang, Controls) der durchzuführenden Überprüfungen liegt vor.",
], high=[], vhigh=[],
impl="Die Einhaltung von Richtlinien, Verfahren und technischen Anforderungen wird organisationsweit nach einem Auditplan durch interne Audits und Kontrollen regelmäßig überprüft; Ergebnisse werden aufgezeichnet und aufbewahrt, Abweichungen als Maßnahmen im ISMS-Tool nachverfolgt.")
DATA["1.5.2"] = dict(policy="R03", title="Unabhängige Überprüfung des ISMS",
must=[
"Informationssicherheitsüberprüfungen werden durch eine unabhängige und kompetente Stelle regelmäßig und nach grundlegenden Änderungen durchgeführt.",
"Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.",
], should=[
"Die Ergebnisse durchgeführter Überprüfungen werden dokumentiert und der Organisationsleitung berichtet.",
], high=[], vhigh=[],
impl="Das ISMS wird regelmäßig und nach grundlegenden Änderungen durch eine unabhängige, kompetente Stelle (interne Revision oder externe Auditierung, z. B. TISAX) überprüft; Ergebnisse werden dokumentiert, der {{ROLE_MANAGEMENT}} berichtet und Abweichungen als Maßnahmen verfolgt.")
DATA["1.6.1"] = dict(policy="R04", title="Meldung von Sicherheitsereignissen",
must=[
"Eine Definition für ein meldepflichtiges Sicherheitsereignis oder eine Beobachtung existiert und ist Beschäftigten und relevanten Stakeholdern bekannt.",
"Angemessene, risikoorientierte Mechanismen zur Meldung von Sicherheitsereignissen sind definiert, umgesetzt und allen relevanten Meldenden bekannt.",
"Angemessene Kanäle zur Kommunikation mit Meldenden existieren.",
], should=[
"Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert.",
"Verschiedene Meldekanäle je nach wahrgenommener Schwere (Echtzeit für gravierende Ereignisse/Notfälle sowie asynchrone Mechanismen wie Tickets oder E-Mail) sind verfügbar.",
"Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden.",
"Sicherheitsereignisse können auch durch Externe gemeldet werden; die einschlägigen Aspekte werden berücksichtigt.",
"Der Mechanismus und die Information, wie Vorfälle gemeldet werden, sind für alle relevanten Meldenden zugänglich.",
"Ein Rückmeldeverfahren an die Meldenden ist etabliert.",
], high=[], vhigh=[
"Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C, I, A)",
],
impl="Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert.",
impl_elev="Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.")
DATA["1.6.2"] = dict(policy="R04", title="Behandlung von Sicherheitsereignissen",
must=[
"Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet.",
"Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt.",
"Lessons Learned fließen in die kontinuierliche Verbesserung ein.",
], should=[
"Gemeldete Ereignisse werden bei der Bearbeitung kategorisiert (z. B. Personal, physisch, Cyber), qualifiziert (z. B. nicht sicherheitsrelevant, Beobachtung, Verbesserungsvorschlag, Schwachstelle, Vorfall) und priorisiert (z. B. gering, mittel, schwer, kritisch).",
"Verantwortlichkeiten für die Behandlung von Ereignissen je Kategorie sind definiert und zugewiesen.",
"Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an zuständige Behörden, sofern erforderlich, existiert. (C, I, A)",
], high=[
"Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A)",
"Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)",
"Gesetzliche, regulatorische und vertragliche Meldepflichten sowie zugehörige Kontaktinformationen sind bekannt. (C, I, A)",
"Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)",
"Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)",
], vhigh=[
"Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßig getestet; die einschlägigen Aspekte werden berücksichtigt. (A)",
],
impl="Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.",
impl_elev="Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskalationen für nicht prioritätsgerecht bearbeitete Ereignisse geregelt, Meldepflichten und Kontakte bekannt, eine Kommunikationsstrategie sowie ein Verfahren für Lieferantenvorfälle etabliert. Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.")
DATA["1.6.3"] = dict(policy="R04", title="Krisenmanagement",
must=[
"Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert und die erforderlichen Ressourcen sind verfügbar.",
"Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert und zugewiesen.",
"Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert.",
], should=[
"Methoden zur Erkennung von Krisensituationen sind etabliert; allgemeine Anzeichen und spezifische vorhersehbare Krisen sind identifiziert.",
"Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden.",
"Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und relevantem Personal bekannt.",
"Ein Krisenstab ist definiert und genehmigt.",
"Krisenrichtlinien und -verfahren sind definiert und genehmigt.",
"Die Krisenplanung wird regelmäßig überprüft und aktualisiert.",
], high=[
"Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert.",
"Notwendige Ressourcen und Informationen zur Krisenbewältigung (z. B. Kommunikationsinfrastruktur, Verfügbarkeit von Kontakt- und Risikoinformationen) sind identifiziert; angemessene Maßnahmen zur Sicherstellung der Verfügbarkeit bzw. Ausfallplanung sind vorhanden. (A)",
"Eine Kommunikationsstrategie für Krisensituationen existiert. (A)",
"Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewertet. (A)",
"Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tabletop-Übungen mit Schlüsselpersonal). (A)",
], vhigh=[
"Krisenübungen und Simulationen unter Einbindung aller relevanten Personen, einschließlich Entscheidungsträger, werden regelmäßig durchgeführt. (A)",
],
impl="Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert; erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.",
impl_elev="Bei hohem Schutzbedarf sind relevante Krisenszenarien identifiziert, notwendige Ressourcen/Informationen und eine Kommunikationsstrategie sichergestellt, die Planung wird regelmäßig bewertet und stichprobenartig getestet (Tabletop). Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.")
DATA["2.1.1"] = dict(policy="R05", title="Qualifikation für sensible Tätigkeiten",
must=[
"Sensible Arbeitsbereiche und Tätigkeiten sind bestimmt.",
"Die Anforderungen an Beschäftigte hinsichtlich ihrer Stellenprofile sind bestimmt und erfüllt.",
"Die Identität potenzieller Beschäftigter wird verifiziert (z. B. Prüfung von Ausweisdokumenten).",
], should=[
"Die persönliche Eignung potenzieller Beschäftigter wird mit einfachen Methoden überprüft (z. B. Vorstellungsgespräch).",
"Eine erweiterte Eignungsprüfung abhängig vom Arbeitsbereich und der Tätigkeit wird durchgeführt (z. B. Assessment-Center, Prüfung von Referenzen, Zeugnissen und Führungszeugnissen).",
], high=[], vhigh=[],
impl="Sensible Tätigkeiten sind bestimmt; Anforderungen an Positionen sind in Stellenbeschreibungen hinterlegt und werden erfüllt. Die Identität wird bei Einstellung verifiziert; die persönliche Eignung wird im rechtlich zulässigen Rahmen geprüft (Gespräch, bei sensiblen Rollen erweiterte Prüfungen wie Referenzen/Führungszeugnis).")
DATA["2.1.2"] = dict(policy="R05", title="Vertragliche Verpflichtung des Personals",
must=[
"Eine Vertraulichkeitsverpflichtung ist in Kraft.",
"Eine Verpflichtung zur Einhaltung der Informationssicherheitsrichtlinien ist in Kraft.",
], should=[
"Eine über den Arbeitsvertrag hinausgehende Vertraulichkeitsverpflichtung ist in Kraft.",
"Informationssicherheitsaspekte werden in den Arbeitsverträgen der Beschäftigten berücksichtigt.",
"Ein Verfahren zum Umgang mit Verstößen gegen diese Verpflichtungen ist beschrieben.",
], high=[], vhigh=[],
impl="Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur Einhaltung der Informationssicherheitsrichtlinien verpflichtet ({{ROLE_HR_LEAD}}); Informationssicherheitsaspekte sind Bestandteil der Arbeitsverträge, die Vertraulichkeit gilt nachvertraglich fort. Ein Verfahren zum Umgang mit Verstößen ist beschrieben; der Nachweis wird in der Personalakte geführt.")
DATA["2.1.3"] = dict(policy="R05", title="Sensibilisierung und Schulung",
must=[
"Beschäftigte werden geschult und sensibilisiert.",
], should=[
"Ein Konzept für Sensibilisierung und Schulung der Beschäftigten ist erstellt.",
"Zielgruppen für Schulungs- und Sensibilisierungsmaßnahmen (z. B. Führungskräfte, Administratoren, Beschäftigte mit Zugang zu Kundennetzen, Fertigungspersonal) sind identifiziert und im Konzept berücksichtigt.",
"Das Konzept ist durch die verantwortliche Leitung genehmigt.",
"Schulungs- und Sensibilisierungsmaßnahmen werden regelmäßig und anlassbezogen durchgeführt.",
"Die Teilnahme an Schulungs- und Sensibilisierungsmaßnahmen wird dokumentiert.",
"Ansprechpartner für Informationssicherheit sind den Beschäftigten bekannt.",
], high=[], vhigh=[],
impl="Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult. Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.")
DATA["2.1.4"] = dict(policy="R06", title="Mobiles Arbeiten",
must=[
"Die Anforderungen an mobiles Arbeiten sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], should=[
"Die einschlägigen Aspekte des mobilen Arbeitens werden berücksichtigt.",
"Sensibilisierung der Beschäftigten.",
], high=[
"Schutzmaßnahmen gegen Abhören und Einsehen sind umgesetzt. (C)",
], vhigh=[],
flag="FLAG_MOBILE_WORK",
impl="Mobiles Arbeiten ist in einer Regelung festgelegt und die Anforderungen sind erfüllt; der Zugriff erfolgt ausschließlich über {{TECH_VPN}} mit MFA (BL-IAM-02) und freigegebene, verschlüsselte Geräte (BL-CRY-03). Die Beschäftigten sind sensibilisiert (BL-HR-01).",
impl_elev="Bei hohem Schutzbedarf sind Schutzmaßnahmen gegen Abhören und Einsehen umgesetzt (z. B. Sichtschutz, ruhige Umgebung, Clean-Screen).")
DATA["3.1.1"] = dict(policy="R07", title="Sicherheitszonen und Zutritt",
must=[
"Ein Sicherheitszonenkonzept einschließlich zugehöriger Schutzmaßnahmen auf Basis der Anforderungen an die Handhabung von Informationswerten ist vorhanden.",
"Die definierten Schutzmaßnahmen sind umgesetzt.",
"Der Verhaltenskodex für Sicherheitszonen ist allen beteiligten Personen bekannt.",
], should=[
"Verfahren für die Vergabe und den Entzug von Zutrittsrechten sind etabliert.",
"Richtlinien für das Besuchermanagement (einschließlich Registrierung und Begleitung von Besuchern) sind definiert.",
"Richtlinien für das Mitführen und Nutzen mobiler IT-Geräte und Datenträger (z. B. Registrierung, Kennzeichnungspflichten) sind definiert und umgesetzt.",
"Netzwerk-/Infrastrukturkomponenten (eigene oder Kundennetze) sind gegen unbefugten Zugriff geschützt.",
"Externe Liegenschaften zur Speicherung/Verarbeitung von Informationswerten sind im Zonenkonzept berücksichtigt (z. B. Lagerräume, Werkstätten, Teststrecken, Rechenzentren).",
], high=[
"Schutzmaßnahmen gegen einfaches Abhören und Einsehen sind umgesetzt. (C)",
], vhigh=[],
impl="Ein Sicherheitszonenkonzept (BL-PHY-01) mit umgesetzten Schutzmaßnahmen und bekanntem Verhaltenskodex ist vorhanden; Zutrittsrechte werden über {{TOOL_TICKET}} bedarfsorientiert vergeben, dokumentiert und bei Wegfall entzogen (BL-PHY-02). Besuchermanagement, Regeln für mobile Geräte, Schutz von Netz-/Infrastrukturkomponenten und externe Liegenschaften sind berücksichtigt.",
impl_elev="Bei hohem Schutzbedarf sind zusätzliche Schutzmaßnahmen gegen einfaches Abhören und Einsehen umgesetzt.")
DATA["3.1.3"] = dict(policy="R07", title="Umgang mit unterstützenden Betriebsmitteln",
must=[], should=[], high=[], vhigh=[],
impl="Der Umgang mit unterstützenden Betriebsmitteln (z. B. Verkabelung, Strom-/Klimaversorgung, Serverräume) ist geregelt; sie sind zutrittsgeschützt, gegen Ausfall abgesichert, werden gewartet und überwacht, für kritische Bereiche bestehen Redundanzen (z. B. USV).")
DATA["3.1.4"] = dict(policy="R06", title="Mobile IT-Geräte und Datenträger",
must=[
"Die Anforderungen an mobile IT-Geräte und mobile Datenträger sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], should=[
"Registrierung der IT-Geräte.",
], high=[
"Generelle Verschlüsselung mobiler Datenträger bzw. der darauf gespeicherten Informationswerte. Wo technisch nicht machbar, werden Informationen durch gleichwertige Maßnahmen geschützt. (C, I)",
], vhigh=[],
flag="FLAG_MOBILE_DEVICES",
impl="Die Anforderungen an mobile Geräte und Datenträger sind bestimmt und erfüllt: Geräte sind über {{TECH_MDM}} registriert und zentral verwaltet, nur freigegebene Geräte werden genutzt; Verlustmeldung erfolgt über den Meldeweg (R04) und {{TOOL_TICKET}}, Sperre/Löschung bei Verlust über {{TECH_MDM}} (BL-EP-02).",
impl_elev="Bei hohem Schutzbedarf sind mobile Datenträger bzw. die darauf gespeicherten Informationen generell verschlüsselt (BL-CRY-03); wo nicht machbar, greifen gleichwertige Schutzmaßnahmen.")
DATA["4.1.1"] = dict(policy="R08", title="Umgang mit Identifikationsmitteln",
must=[
"Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], should=[
"Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden.",
], high=[
"Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall ist vorbereitet und soweit möglich umgesetzt. (C, I, A)",
], vhigh=[],
impl="Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).",
impl_elev="Bei hohem Schutzbedarf besteht eine umgesetzte Strategie zur Sperrung/Ungültigmachung von Identifikationsmitteln im Verlustfall.")
DATA["4.1.2"] = dict(policy="R08", title="Sichere Anmeldung",
must=[
"Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewählt; mögliche Angriffsszenarien (z. B. direkte Erreichbarkeit über das Internet) wurden berücksichtigt.",
"Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.",
], should=[
"Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt.",
"Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert.",
"Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. Privileged Access Management, Zwei-Faktor-Authentifizierung).",
], high=[
"Abhängig von der Risikobewertung sind Authentifizierung und Zugangskontrolle durch ergänzende Maßnahmen verstärkt (z. B. kontinuierliche Zugriffsüberwachung, starke Authentifizierung, automatische Abmeldung, Sperre bei Inaktivität, Brute-Force-Prävention). (C, I, A)",
], vhigh=[
"Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Authentifizierung (z. B. Zwei-Faktor) nach dem Stand der Technik authentifiziert. (C, I)",
],
impl="Die Authentifizierungsverfahren sind risikobasiert ausgewählt und entsprechen dem Stand der Technik; Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden zentral über {{TOOL_IAM}} erzwungen. Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA (BL-IAM-02) über {{TECH_MFA}} durchgesetzt; privilegierte Konten nutzen höherwertige Verfahren (PAM).",
impl_elev="Bei hohem Schutzbedarf sind Authentifizierung/Zugangskontrolle durch ergänzende Maßnahmen verstärkt (Zugriffsüberwachung, Auto-Logout BL-IAM-03, Sperre BL-IAM-04, Brute-Force-Schutz). Bei sehr hohem Schutzbedarf erfolgt der Zugriff nur nach starker Authentifizierung (Zwei-Faktor).")
DATA["4.1.3"] = dict(policy="R08", title="Benutzerkonten und Anmeldeinformationen",
must=[
"Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt.",
"Eindeutige und personalisierte Benutzerkonten werden verwendet.",
"Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist).",
"Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende).",
"Benutzerkonten werden regelmäßig überprüft.",
"Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt.",
"Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], should=[
"Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt.",
"Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung).",
"Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert.",
"Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip).",
"Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert.",
"Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert.",
"Die Verwendung von Standardpasswörtern wird technisch verhindert.",
"Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher.",
"Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden.",
"Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert.",
], high=[], vhigh=[],
impl="Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) eindeutig personalisiert in {{TOOL_IAM}} verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.")
DATA["4.2.1"] = dict(policy="R08", title="Zugriffsrechte",
must=[
"Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Die für normale und privilegierte Benutzerkonten sowie technische Konten vergebenen Zugriffsrechte werden regelmäßig überprüft, auch in IT-Systemen von Kunden.",
], should=[
"Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet.",
"Autorisierungsrollen werden verwendet.",
"Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben.",
"Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte.",
"Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert.",
], high=[
"Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A)",
], vhigh=[
"Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unbefugten Zugriff (auch privilegierter Nutzer) zu verhindern. Wo Verschlüsselung nicht machbar ist, greifen gleichwertige Maßnahmen. (C)",
"Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C)",
],
impl="Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}. Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.",
impl_elev="Bei hohem Schutzbedarf werden Zugriffsrechte durch den verantwortlichen internen Information Officer genehmigt. Bei sehr hohem Schutzbedarf werden Informationen inhaltsverschlüsselt gespeichert (Schutz auch vor privilegierten Nutzern) und Zugriffsrechte in kürzeren Abständen (z. B. quartalsweise) überprüft.")
DATA["5.1.1"] = dict(policy="R09", title="Einsatz kryptografischer Verfahren",
must=[
"Alle eingesetzten kryptografischen Verfahren (z. B. Verschlüsselung, Signatur, Hash-Algorithmen, Protokolle) bieten die im jeweiligen Anwendungsfeld erforderliche Sicherheit nach anerkanntem Industriestandard, soweit rechtlich möglich.",
], should=[
"Ein Konzept für den Einsatz von Kryptografie ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], high=[
"Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) sind bestimmt und erfüllt. (C, I)",
], vhigh=[],
impl="Zulässige Verfahren und Schlüssellängen nach BL-CRY-02 ({{CRYPTO_ALGO}}) entsprechen dem anerkannten Industriestandard und sind vorgegeben; veraltete Verfahren sind untersagt. Ein Kryptokonzept ist dokumentiert (siehe {{LINK:VA-07}}), Schlüssel werden über ihren Lebenszyklus sicher verwaltet (BL-CRY-05).",
impl_elev="Bei hohem Schutzbedarf sind Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) bestimmt und erfüllt.")
DATA["5.1.2"] = dict(policy="R09", title="Schutz bei der Informationsübertragung",
must=[
"Die zur Informationsübertragung genutzten Netzdienste sind identifiziert und dokumentiert.",
"Richtlinien und Verfahren entsprechend den Klassifizierungsanforderungen für die Nutzung von Netzdiensten sind definiert und umgesetzt.",
"Maßnahmen zum Schutz übertragener Inhalte gegen unbefugten Zugriff sind umgesetzt.",
], should=[
"Maßnahmen zur Sicherstellung korrekter Adressierung und korrekter Informationsübertragung sind umgesetzt.",
"Elektronischer Datenaustausch erfolgt mittels Inhalts- oder Transportverschlüsselung entsprechend der jeweiligen Klassifizierung.",
"Fernzugriffsverbindungen zum Netzwerk der Organisation verfügen über angemessene Sicherheitsmerkmale; dabei werden die einschlägigen Aspekte berücksichtigt.",
], high=[
"Informationen werden verschlüsselt übertragen (mindestens Transportverschlüsselung) oder durch gleichwertig wirksame Maßnahmen geschützt. (C)",
], vhigh=[
"Informationen werden inhaltsverschlüsselt übertragen. (C)",
],
impl="Genutzte Netzdienste sind identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04).",
impl_elev="Bei hohem Schutzbedarf werden Informationen mindestens transportverschlüsselt oder gleichwertig geschützt übertragen; bei sehr hohem Schutzbedarf erfolgt eine Inhaltsverschlüsselung.")
DATA["5.2.1"] = dict(policy="R10", title="Änderungsmanagement (Change)",
must=[
"Informationssicherheitsanforderungen für Änderungen an Organisation, Geschäftsprozessen und IT-Systemen sind bestimmt und erfüllt.",
], should=[
"Ein formales Genehmigungsverfahren ist etabliert.",
"Die möglichen Auswirkungen von Änderungen auf die Informationssicherheit werden bewertet.",
"Änderungen mit Auswirkung auf die Informationssicherheit werden geplant und getestet.",
"Verfahren zum Rückfall (Fallback) in Fehlerfällen werden berücksichtigt.",
], high=[
"Die Einhaltung der Informationssicherheitsanforderungen wird während und nach den Änderungen überprüft. (C, I, A)",
], vhigh=[],
impl="Änderungen durchlaufen ein formales Change-Verfahren mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.",
impl_elev="Bei hohem Schutzbedarf wird die Einhaltung der Informationssicherheitsanforderungen während und nach der Änderung verifiziert.")
DATA["5.2.2"] = dict(policy="R10", title="Trennung von Entwicklungs-, Test- und Produktivsystemen",
must=[
"Die IT-Systeme wurden einer Risikobewertung unterzogen, um die Notwendigkeit ihrer Trennung in Entwicklungs-, Test- und Produktivsysteme zu bestimmen.",
"Eine Segmentierung ist auf Basis der Ergebnisse der Risikoanalyse umgesetzt.",
], should=[
"Die Anforderungen an Entwicklungs- und Testumgebungen sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.",
], high=[], vhigh=[],
impl="Auf Basis einer Risikobewertung sind Entwicklung, Test und Produktion getrennt betrieben und segmentiert; Anforderungen an Entwicklungs-/Testumgebungen sind bestimmt und erfüllt, Produktivdaten werden dort nur anonymisiert/pseudonymisiert genutzt.")
DATA["5.2.3"] = dict(policy="R10", title="Schutz vor Schadsoftware",
must=[
"Anforderungen zum Schutz vor Schadsoftware sind bestimmt.",
"Technische und organisatorische Maßnahmen zum Schutz vor Schadsoftware sind definiert und umgesetzt.",
], should=[
"Unnötige Netzwerkdienste sind deaktiviert.",
"Der Zugriff auf Netzwerkdienste ist durch geeignete Schutzmaßnahmen auf das Notwendige beschränkt.",
"Schutzsoftware gegen Schadsoftware ist installiert und wird regelmäßig automatisch aktualisiert (z. B. Virenscanner).",
"Empfangene Dateien und Software werden vor der Ausführung automatisch auf Schadsoftware geprüft (On-Access-Scan).",
"Der gesamte Datenbestand aller Systeme wird regelmäßig auf Schadsoftware geprüft.",
"Über zentrale Gateways übertragene Daten (z. B. E-Mail, Internet, Fremdnetze) werden automatisch durch Schutzsoftware geprüft.",
"Maßnahmen, die verhindern, dass Schutzsoftware durch Nutzer deaktiviert oder verändert wird, sind definiert und umgesetzt.",
"Für IT-Systeme ohne Schutzsoftware sind alternative Maßnahmen umgesetzt (z. B. besondere Resilienz, wenige Dienste, keine aktiven Nutzer, Netzisolation).",
], high=[], vhigh=[],
impl="Malware-Schutz ist über {{TECH_MALWARE}} auf allen Endpunkten und Servern umgesetzt (BL-OPS-03); Signaturen/Engines aktualisieren sich {{MALWARE_UPDATE}}, On-Access- und regelmäßige Vollscans sowie Gateway-Prüfungen (E-Mail/Internet) sind aktiv. Unnötige Netzwerkdienste sind deaktiviert, der Zugriff ist beschränkt, das Deaktivieren der Schutzsoftware ist unterbunden; für Systeme ohne Schutzsoftware greifen alternative Maßnahmen (Isolation).")
DATA["5.2.4"] = dict(policy="R10", title="Protokollierung und Auswertung",
must=[
"Informationssicherheitsanforderungen an den Umgang mit Ereignisprotokollen sind bestimmt und erfüllt.",
"Sicherheitsrelevante Anforderungen an die Protokollierung von Aktivitäten von Administratoren und Nutzern sind bestimmt und erfüllt.",
"Die eingesetzten IT-Systeme werden hinsichtlich der Notwendigkeit der Protokollierung bewertet.",
"Bei Nutzung externer IT-Dienste werden Informationen zu den Überwachungsmöglichkeiten eingeholt und in der Bewertung berücksichtigt.",
"Ereignisprotokolle werden regelmäßig auf Richtlinienverstöße und auffällige Probleme geprüft, unter Einhaltung der zulässigen rechtlichen und organisatorischen Vorgaben.",
], should=[
"Ein Verfahren zur Eskalation relevanter Ereignisse an die verantwortliche Stelle ist definiert und etabliert.",
"Ereignisprotokolle (Inhalt und Metadaten) sind gegen Veränderung geschützt (z. B. durch eine dedizierte Umgebung).",
"Eine angemessene Überwachung und Aufzeichnung aller informationssicherheitsrelevanten Aktionen im Netzwerk ist etabliert.",
], high=[
"Sicherheitsrelevante Anforderungen an den Umgang mit Ereignisprotokollen, z. B. vertragliche Anforderungen, sind bestimmt und umgesetzt. (C, I, A)",
"Ereignisse zu Auf- und Abbau von Fernzugriffssitzungen (z. B. Fernwartung) werden protokolliert. (C, I, A)",
], vhigh=[
"Protokollierung jedes Zugriffs auf Daten mit sehr hohem Schutzbedarf, soweit technisch machbar und rechtlich/organisatorisch zulässig. (C, I)",
],
impl="Sicherheitsrelevante Ereignisse (inkl. Administrator-/Nutzeraktivitäten) werden nach bestimmten und bewerteten Anforderungen zentral über {{TECH_SIEM}} protokolliert und regelmäßig auf Verstöße ausgewertet (BL-OPS-04); bei externen Diensten werden Überwachungsmöglichkeiten berücksichtigt. Protokolle sind manipulationsgeschützt, Aufbewahrung {{LOG_RETENTION}}, ein Eskalationsverfahren ist etabliert (siehe {{LINK:VA-13}}).",
impl_elev="Bei hohem Schutzbedarf sind zusätzliche (z. B. vertragliche) Protokollanforderungen umgesetzt und Fernzugriffssitzungen werden protokolliert. Bei sehr hohem Schutzbedarf wird jeder Zugriff auf entsprechende Daten protokolliert, soweit technisch/rechtlich zulässig.")
DATA["5.2.5"] = dict(policy="R10", title="Umgang mit Schwachstellen",
must=[
"Informationen über technische Schwachstellen der eingesetzten IT-Systeme werden erhoben (z. B. Herstellerinfos, System-Audits, CVE-Datenbank).",
"Potenziell betroffene IT-Systeme und Software werden identifiziert und das durch die Schwachstelle verursachte Risiko wird bewertet.",
"Risiken aus Schwachstellen werden behandelt.",
], should=[
"Ein angemessenes Patch-Management ist definiert und umgesetzt (z. B. Patch-Test und -Installation).",
"Risikominimierende Maßnahmen werden bei Bedarf umgesetzt.",
"Die erfolgreiche Installation von Patches wird in geeigneter Weise verifiziert.",
], high=[], vhigh=[],
impl="Schwachstelleninformationen werden erhoben (Herstellerinfos, CVE, Scans BL-OPS-02), betroffene Systeme identifiziert, das Risiko bewertet und nach BL-OPS-01 risikoorientiert über Patch-/Change-Management (siehe {{LINK:VA-06}}) behandelt (kritisch {{PATCH_SLA_CRIT}}); die erfolgreiche Installation wird verifiziert und im {{TOOL_TICKET}} nachverfolgt, risikominimierende Maßnahmen greifen bei Bedarf.")
DATA["5.2.6"] = dict(policy="R10", title="Technische Überprüfung von IT-Systemen",
must=[
"Anforderungen an die Prüfung (Audit) von IT-Systemen oder -Diensten sind bestimmt.",
"Der Umfang der Systemprüfung wird rechtzeitig festgelegt.",
"System- oder Dienstprüfungen werden mit Betreiber und Nutzern der IT-Systeme/-Dienste abgestimmt.",
"Die Ergebnisse von System-/Dienstprüfungen werden nachvollziehbar gespeichert und der zuständigen Leitung berichtet.",
"Aus den Ergebnissen werden Maßnahmen abgeleitet und in angemessener Frist umgesetzt.",
], should=[
"System- und Dienstprüfungen werden unter Berücksichtigung möglicher Sicherheitsrisiken (z. B. Störungen) geplant.",
"Regelmäßige System- oder Dienstprüfungen werden durchgeführt; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Innerhalb einer angemessenen Frist nach Abschluss der Prüfung wird ein Bericht erstellt.",
], high=[
"Für kritische IT-Systeme/-Dienste wurden zusätzliche Prüfanforderungen identifiziert und werden erfüllt (z. B. dienstspezifische Tests/Werkzeuge und/oder manuelle Penetrationstests, risikobasierte Intervalle). (A)",
], vhigh=[
"IT-Systeme und -Dienste werden regelmäßig auf Schwachstellen gescannt. Für nicht scanbare Systeme/Dienste sind geeignete Schutzmaßnahmen umzusetzen. (C, I, A)",
],
impl="Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft. Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.",
impl_elev="Bei hohem Schutzbedarf werden für kritische Systeme zusätzliche Prüfungen (Penetrationstests {{PENTEST_FREQ}}, BL-OPS-08) durchgeführt. Bei sehr hohem Schutzbedarf werden Systeme regelmäßig auf Schwachstellen gescannt bzw. nicht scanbare durch geeignete Maßnahmen geschützt.")
DATA["5.2.7"] = dict(policy="R10", title="Netzwerksicherheit",
must=[
"Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und erfüllt.",
"Anforderungen an die Netzsegmentierung sind bestimmt und erfüllt.",
], should=[
"Verfahren für das Management und die Steuerung von Netzwerken sind definiert.",
"Für eine risikobasierte Netzsegmentierung werden die einschlägigen Aspekte berücksichtigt.",
], high=[
"Erweiterte Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und umgesetzt. (C, I, A)",
], vhigh=[],
impl="Das Netzwerk ist nach Schutzbedarf risikobasiert segmentiert (BL-NET-01), zugangskontrolliert und nach außen über Firewall (Default-Deny, BL-NET-02) abgesichert; Management-/Steuerungsverfahren und ein aktueller Netzplan/Segmentierungskonzept werden gepflegt.{{#if FLAG_OT_USED}} Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert.{{/if}}",
impl_elev="Bei hohem Schutzbedarf sind erweiterte Anforderungen an Netzmanagement und -steuerung bestimmt und umgesetzt.")
DATA["5.2.8"] = dict(policy="R04", title="Kontinuitätsplanung für IT-Dienste",
must=[
"Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt.",
"Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung dieser IT-Dienste sind relevanten Stakeholdern bekannt und erfüllt.",
], should=[
"Kritische IT-Systeme sind identifiziert; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert.",
"Die Kontinuitätsplanung umfasst mindestens (D)DoS-Angriffe, erfolgreiche Ransomware-Angriffe und andere Sabotage, Systemausfallszenarien sowie Naturkatastrophen, die kritische IT-Systeme betreffen.",
], high=[
"Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (Recovery Time Objective) für die Wiederaufnahme des Betriebs. (A)",
"Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen. (A)",
"Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit Geschäftspartnern. (A)",
"Die Kontinuitätsplanung wird regelmäßig getestet, inkl. vollständiger Wiederherstellung in einen bekannten Zustand und Einhaltung definierter Zielzeiten. (A)",
"Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste und Informationen ist definiert und umgesetzt. (C, I, A)",
"Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugte Veränderung/Löschung durch Schadsoftware geschützt. (I, A)",
"Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugten Zugriff durch Schadsoftware oder Betreiber geschützt. (C, I)",
], vhigh=[
"Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister abgestimmt. (A)",
"Die Fortführung wesentlicher Kern- und Geschäftsfunktionen mit minimalem oder keinem Verlust an Betriebskontinuität ist möglich; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Die Kontinuitätsplanung wird regelmäßig getestet. Testszenarien, Ergebnisse und Lessons Learned werden aufgezeichnet. (I, A)",
],
impl="Kritische IT-Dienste sind mit Geschäftsauswirkung identifiziert; Anforderungen und Verantwortlichkeiten für Kontinuität/Wiederherstellung sind bekannt und erfüllt. Eine Kontinuitätsplanung (inkl. (D)DoS, Ransomware, Ausfall, Naturkatastrophen) besteht, wird regelmäßig überprüft und über das IT-Notfallverfahren umgesetzt (siehe {{LINK:VA-02}}).",
impl_elev="Bei hohem Schutzbedarf sind RTO/RPO, SLAs mit Dienstleistern, Partnerkommunikation, regelmäßige Volltests sowie eine geschützte Backup-/Recovery-Strategie (immutable/isoliert) etabliert. Bei sehr hohem Schutzbedarf ist die Planung mit externen Dienstleistern abgestimmt, die Fortführung wesentlicher Funktionen sichergestellt und Tests inkl. Lessons Learned werden aufgezeichnet.")
DATA["5.2.9"] = dict(policy="R10", title="Datensicherung und Wiederherstellung",
must=[
"Backup-Konzepte existieren für relevante IT-Systeme. Angemessene Schutzmaßnahmen für Vertraulichkeit, Integrität und Verfügbarkeit der Datensicherungen werden berücksichtigt.",
"Wiederherstellungskonzepte existieren für relevante IT-Dienste.",
], should=[
"Für jeden relevanten IT-Dienst existiert ein Backup- und Wiederherstellungskonzept. Abhängigkeiten zwischen IT-Diensten und die Reihenfolge der Wiederherstellung werden berücksichtigt.",
], high=[
"Backup- und Wiederherstellungskonzepte werden methodisch in regelmäßigen Abständen überprüft. (A)",
"Die grundsätzliche Wiederherstellbarkeit wird berücksichtigt und getestet (z. B. Stichprobentests, Testsysteme). (I, A)",
], vhigh=[
"(Zusätzliche) Backups werden über Offline-Verfahren, unveränderliche (immutable) Backups oder eine isolierte IAM-Lösung durchgeführt. (I, A)",
"Wiederherstellungsverfahren werden methodisch in regelmäßigen Abständen technisch getestet. (I, A)",
"Geografische Redundanz wird in Backup- und Wiederherstellungskonzepten berücksichtigt. (A)",
],
impl="Backup- und Wiederherstellungskonzepte für relevante IT-Dienste bestehen (Schutz von Vertraulichkeit/Integrität/Verfügbarkeit, Abhängigkeiten und Reihenfolge berücksichtigt); Sicherung erfolgt nach Schema {{BACKUP_SCHEME}} über {{TECH_BACKUP}} (BL-OPS-05), Aufbewahrung {{BACKUP_RETENTION}}, Wiederherstellung geregelt und getestet (siehe {{LINK:VA-05}}).",
impl_elev="Bei hohem Schutzbedarf werden Konzepte methodisch überprüft und die Wiederherstellbarkeit getestet. Bei sehr hohem Schutzbedarf erfolgen zusätzliche Offline-/immutable-Backups, methodische technische Restore-Tests und geografische Redundanz.")
DATA["5.3.1"] = dict(policy="R11", title="Sicherheit bei Beschaffung und Entwicklung",
must=[
"Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.",
"Die mit Beschaffung oder Erweiterung von IT-Diensten und -Komponenten verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.",
"Informationssicherheitsanforderungen im Zusammenhang mit Änderungen an entwickelten IT-Diensten werden berücksichtigt.",
"Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt.",
], should=[
"Anforderungsspezifikationen werden erstellt; dabei werden die einschlägigen Aspekte berücksichtigt.",
"Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft.",
"Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft.",
"Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden (ggf. Anonymisierung/Pseudonymisierung); dabei werden die einschlägigen Aspekte berücksichtigt.",
"Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten für Tests genutzt werden.",
], high=[], vhigh=[
"Die Sicherheit zweckgebauter oder wesentlich angepasster Software wird bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (z. B. Penetrationstest). (C, I, A)",
],
impl="Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikationen werden erstellt und geprüft, Abnahmetests unter Sicherheitsaspekten durchgeführt, Produktivsetzung erst nach Prüfung im {{TOOL_TICKET}}. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan).{{/if}}",
impl_elev="Bei sehr hohem Schutzbedarf wird die Sicherheit zweckgebauter oder wesentlich angepasster Software bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (Penetrationstest).")
DATA["5.3.2"] = dict(policy="R11", title="Anforderungen an Netzdienste",
must=[
"Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt.",
], should=[
"Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt.",
"Die Anforderungen werden in Form von SLAs vereinbart.",
"Angemessene Redundanzlösungen sind umgesetzt.",
], high=[
"Verfahren zur Überwachung der Qualität des Netzverkehrs (z. B. Traffic-Flow-Analysen, Verfügbarkeitsmessungen) sind definiert und werden durchgeführt. (A)",
], vhigh=[],
impl="Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen bestimmt, in SLAs vereinbart und über ein Verfahren umgesetzt; angemessene Redundanzen bestehen.",
impl_elev="Bei hohem Schutzbedarf werden Verfahren zur Überwachung der Netzverkehrsqualität (Traffic-Flow-Analysen, Verfügbarkeitsmessungen) definiert und durchgeführt.")
DATA["5.3.3"] = dict(policy="R11", title="Rückgabe und sichere Löschung",
must=[], should=[
"Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt.",
], high=[], vhigh=[],
impl="Rückgabe und sichere Löschung/Vernichtung von Informationen und Assets (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt, vertraglich vereinbart, an Änderungen angepasst und werden nachgewiesen (Löschprotokoll).")
DATA["5.3.4"] = dict(policy="R12", title="Schutz in geteilten externen IT-Diensten",
must=[
"Eine wirksame Trennung (z. B. Mandantentrennung) verhindert den Zugriff unbefugter Nutzer anderer Organisationen auf eigene Informationen.",
], should=[
"Das Trennungskonzept des Anbieters ist dokumentiert und an Änderungen angepasst; dabei werden die einschlägigen Aspekte berücksichtigt.",
], high=[], vhigh=[],
impl="Bei geteilten externen IT-Diensten wird eine wirksame Mandantentrennung gefordert und vertraglich zugesichert; das Trennungskonzept des Anbieters wird dokumentiert und bei Änderungen aktualisiert.{{#if FLAG_CLOUD_USED}} Cloud-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt (siehe {{LINK:VA-11}}).{{/if}}")
DATA["6.1.1"] = dict(policy="R13", title="Informationssicherheit bei Lieferanten",
must=[
"Auftragnehmer und Partner werden einer Sicherheitsrisikobewertung unterzogen.",
"Ein angemessenes Informationssicherheitsniveau wird durch vertragliche Vereinbarungen mit Auftragnehmern und Partnern sichergestellt.",
"Sofern zutreffend, werden vertragliche Vereinbarungen mit Auftraggebern/Kunden an Auftragnehmer und Partner weitergegeben.",
], should=[
"Auftragnehmer und Partner sind vertraglich verpflichtet, Anforderungen an ein angemessenes Informationssicherheitsniveau an ihre Unterauftragnehmer weiterzugeben.",
"Leistungsberichte und Dokumente von Auftragnehmern und Partnern werden geprüft.",
], high=[
"Es wird nachgewiesen, dass das Informationssicherheitsniveau des Lieferanten dem Schutzbedarf angemessen ist (z. B. geprüfter Fragebogen/Selbstauskunft, Attestierung, Zertifikat, Lieferantenaudit). (C, I, A)",
"Der Grad der Erfüllung geforderter Nachweise durch den Lieferanten wird dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. (C, I, A)",
"Die Einhaltung vertraglicher Vereinbarungen durch den Lieferanten wird geprüft, dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. (C, I, A)",
], vhigh=[
"Das angemessene Informationssicherheitsniveau sollte durch ein Drittparteien-Audit (angemessenes TISAX-Label o. Ä.) oder ein angemessenes Lieferantenaudit nachgewiesen werden. Ohne Audit muss die Leitung eine risikobasierte Entscheidung zur Fortführung treffen; ein Nachweis dieser Entscheidung existiert. (C, I, A)",
"Vertragliche Verpflichtungen gegenüber Kunden zur Transparenz von Lieferkettenrisiken werden erfüllt. (C, I, A)",
],
impl="Auftragnehmer/Partner werden einer Sicherheitsrisikobewertung (BL-SUP-01) unterzogen und vertraglich auf ein angemessenes Informationssicherheitsniveau (inkl. Weitergabe an Unterauftragnehmer und Kundenanforderungen) verpflichtet; das Lieferantenverzeichnis wird im ISMS-Tool ({{TOOL_NAME}}) geführt, Leistungsberichte werden geprüft (siehe {{LINK:VA-10}}).",
impl_elev="Bei hohem Schutzbedarf wird das Sicherheitsniveau des Lieferanten nachgewiesen (Selbstauskunft/Attest/Zertifikat/Audit) und die Einhaltung dokumentiert, regelmäßig und bei Änderungen überwacht. Bei sehr hohem Schutzbedarf erfolgt der Nachweis über ein Drittparteien-Audit (TISAX o. Ä.) oder eine dokumentierte risikobasierte Leitungsentscheidung; Transparenzpflichten zu Lieferkettenrisiken werden erfüllt.")
DATA["6.1.2"] = dict(policy="R13", title="Vertraulichkeitsvereinbarungen",
must=[
"Die Vertraulichkeitsanforderungen sind bestimmt und erfüllt.",
"Anforderungen und Verfahren zur Anwendung von Vertraulichkeitsvereinbarungen sind allen Personen bekannt, die schutzbedürftige Informationen weitergeben.",
"Gültige Vertraulichkeitsvereinbarungen werden vor der Weitergabe schutzbedürftiger Informationen abgeschlossen.",
"Die Anforderungen und Verfahren zur Nutzung von Vertraulichkeitsvereinbarungen und zum Umgang mit schutzbedürftigen Informationen werden regelmäßig überprüft.",
], should=[
"Vorlagen für Vertraulichkeitsvereinbarungen sind vorhanden und auf rechtliche Anwendbarkeit geprüft.",
"Vertraulichkeitsvereinbarungen umfassen beteiligte Personen/Organisationen, Art der Informationen, Gegenstand, Gültigkeitsdauer und Verantwortlichkeiten der verpflichteten Partei.",
"Vertraulichkeitsvereinbarungen enthalten Regelungen zum Umgang mit schutzbedürftigen Informationen über die Vertragsbeziehung hinaus.",
"Möglichkeiten zum Nachweis der Einhaltung (z. B. Prüfung durch unabhängige Dritte oder Auditrechte) sind definiert.",
"Ein Prozess zur Überwachung der Gültigkeitsdauer temporärer Vertraulichkeitsvereinbarungen und zur rechtzeitigen Verlängerung ist definiert und umgesetzt.",
], high=[], vhigh=[],
impl="Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.")
DATA["6.1.3"] = dict(policy="R13", title="Abgrenzung der Verantwortlichkeiten",
must=[
"Die betroffenen IT-Dienste sind identifiziert.",
"Die für den IT-Dienst relevanten Sicherheitsanforderungen sind bestimmt.",
"Die für die Umsetzung der Anforderung verantwortliche Organisation ist definiert und sich ihrer Verantwortung bewusst.",
"Mechanismen für geteilte Verantwortlichkeiten sind spezifiziert und umgesetzt.",
"Die verantwortliche Organisation erfüllt ihre jeweiligen Verantwortlichkeiten.",
], should=[
"Bei IT-Diensten ist die Konfiguration auf Basis der notwendigen Sicherheitsanforderungen konzipiert, umgesetzt und dokumentiert.",
"Das verantwortliche Personal ist angemessen geschult.",
], high=[
"Eine Liste der betroffenen IT-Dienste und der jeweils verantwortlichen IT-Dienstleister existiert. (C, I, A)",
"Die Anwendbarkeit der ISA-Controls wurde bewertet und dokumentiert. (C, I, A)",
"Die Dienstkonfiguration ist in die regelmäßigen Sicherheitsbewertungen einbezogen. (C, I, A)",
"Es wird nachgewiesen, dass die IT-Dienstleister ihre Verantwortung erfüllen. (C, I, A)",
"Die Integration in lokale Schutzmaßnahmen (z. B. sichere Authentifizierungsmechanismen) ist etabliert und dokumentiert. (C, I, A)",
], vhigh=[],
impl="Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt. Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.",
impl_elev="Bei hohem Schutzbedarf existiert eine Liste der IT-Dienste und verantwortlichen Dienstleister, die Anwendbarkeit der ISA-Controls ist bewertet/dokumentiert, die Dienstkonfiguration ist Teil regelmäßiger Sicherheitsbewertungen, die Verantwortungserfüllung wird nachgewiesen und die Integration in lokale Schutzmaßnahmen ist dokumentiert.")
DATA["7.1.1"] = dict(policy="R14", title="Regulatorische und vertragliche Compliance",
must=[
"Rechtliche, regulatorische und vertragliche Vorgaben mit Relevanz für die Informationssicherheit werden regelmäßig bestimmt.",
"Richtlinien zur Einhaltung der Vorgaben sind definiert, umgesetzt und den verantwortlichen Personen kommuniziert.",
], should=[
"Die Integrität von Aufzeichnungen entsprechend rechtlichen, regulatorischen und vertraglichen Vorgaben sowie Geschäftsanforderungen wird berücksichtigt.",
], high=[], vhigh=[],
impl="Relevante rechtliche, regulatorische und vertragliche Anforderungen werden regelmäßig bestimmt und in einem Compliance-/Rechtsregister im ISMS-Tool ({{TOOL_NAME}}) erfasst; Richtlinien zur Einhaltung sind definiert, umgesetzt und den Verantwortlichen kommuniziert, die Integrität von Aufzeichnungen wird berücksichtigt.")
DATA["7.1.2"] = dict(policy="R14", title="Schutz personenbezogener Daten",
must=[
"Rechtliche und vertragliche Informationssicherheitsanforderungen an Verfahren und Prozesse bei der Verarbeitung personenbezogener Daten sind bestimmt.",
"Regelungen zur Einhaltung rechtlicher und vertraglicher Anforderungen an den Schutz personenbezogener Daten sind definiert und den beteiligten Personen bekannt.",
"Prozesse und Verfahren zum Schutz personenbezogener Daten sind im Informationssicherheits-Managementsystem berücksichtigt.",
], should=[], high=[], vhigh=[],
flag="FLAG_PERSONAL_DATA",
impl="Rechtliche und vertragliche Anforderungen an die Verarbeitung personenbezogener Daten (DSGVO) sind bestimmt; Regelungen sind definiert, den Beteiligten bekannt und im ISMS berücksichtigt. {{ROLE_DPO}} ist eingebunden, das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt, TOM und Löschkonzepte (BL-DEL-01) sind geregelt.")
# ---- Nicht-ISA-Zusatz (kundenspezifisch): KI-/GenAI-Nutzung, an R12 angehaengt ----
CUSTOM = {}
CUSTOM["5.3.4-KI"] = dict(policy="R12", title="Nutzung von KI-/GenAI-Diensten", flag="FLAG_AI_USED",
must=[
"Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutzt.",
"Die Eingabe vertraulicher oder personenbezogener Informationen in nicht freigegebene KI-Dienste ist untersagt; zulässige Datenklassen je Dienst sind definiert.",
"Bei freigegebenen KI-Diensten ist geklärt und vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden.",
], should=[
"Ergebnisse von KI-Diensten werden vor geschäftskritischer Verwendung geprüft (Human-in-the-Loop); der KI-Einsatz wird dokumentiert und regulatorische Anforderungen (z. B. EU AI Act) berücksichtigt.",
], high=[], vhigh=[],
impl="Der Einsatz von KI-/GenAI-Diensten ist geregelt; nur von {{ROLE_ISB}} freigegebene Dienste (Freigabeliste im ISMS-Tool) dürfen genutzt werden (siehe {{LINK:VA-11}}). Zulässige Datenklassen je Dienst sind definiert, die Eingabe vertraulicher/personenbezogener Daten in nicht freigegebene Dienste ist untersagt; bei Freigabe ist vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden. KI-Ergebnisse werden vor kritischer Verwendung geprüft (Human-in-the-Loop), der Einsatz dokumentiert und der EU AI Act berücksichtigt.")
seed/isms-vorlagenpaket-v2/_iso_crosswalk.json
+1735
View File
File diff suppressed because it is too large Load Diff
seed/isms-vorlagenpaket-v2/_iso_sections.json
+81
View File
@@ -0,0 +1,81 @@
{
"hinweis": "Redaktionell pflegbare Texte der ISO-only-Abschnitte. Individualisierung ausschließlich über {{VARIABLEN}} und Baseline-IDs (BL-*) — keine Klartextwerte eintragen.",
"abschnitte": {
"ISO-LEITLINIE": {
"titel": "Informationssicherheitspolitik, Ziele und Kommunikation",
"umsetzung": "Diese Leitlinie wird von der {{ROLE_MANAGEMENT}} freigegeben, im {{TOOL_NAME}} veröffentlicht und allen Beschäftigten sowie relevanten Dritten bekannt gemacht; die Kenntnisnahme wird je Fassung dokumentiert. Die Überprüfung erfolgt mindestens {{POLICY_REVIEW_CYCLE}} sowie bei wesentlichen Änderungen (BL-GOV-03). Die themenspezifischen Richtlinien und die Verfahrensanweisungen konkretisieren sie und durchlaufen denselben Freigabe- und Prüfzyklus. Die Informationssicherheitsziele sind messbar formuliert und mit Zielwert, verantwortlicher Rolle und Termin im {{TOOL_NAME}} hinterlegt; ihre Erreichung wird {{MGMT_REVIEW_CYCLE}} bewertet. Für die interne und externe Kommunikation zur Informationssicherheit ist festgelegt, worüber, wann, mit wem und durch wen kommuniziert wird; zentraler Ansprechpartner ist {{ROLE_ISB}}."
},
"ISO-MS-KONTEXT": {
"titel": "Kontext, interessierte Parteien und Anwendungsbereich des ISMS",
"umsetzung": "Interne und externe Themen sowie die relevanten interessierten Parteien und deren Anforderungen werden im {{TOOL_NAME}} als Kontext- und Stakeholderanalyse geführt und mindestens {{POLICY_REVIEW_CYCLE}} sowie bei wesentlichen Änderungen aktualisiert. Der Anwendungsbereich des ISMS ({{ISMS_SCOPE}}) ist als dokumentierte Information festgelegt und benennt Standorte, Prozesse, Organisationseinheiten und IT-Dienste sowie Schnittstellen und Abhängigkeiten zu Dritten; Ausschlüsse werden begründet. Das ISMS wird nach dem PDCA-Zyklus betrieben und fortlaufend verbessert. Verantwortlich: {{ROLE_ISB}}; Freigabe: {{ROLE_MANAGEMENT}}."
},
"ISO-MS-CHANGE": {
"titel": "Planung von Änderungen am ISMS",
"umsetzung": "Änderungen am ISMS — Anwendungsbereich, Organisation, Rollen, wesentliche Prozesse oder Systeme — werden geplant, vor der Umsetzung bewertet und im {{TOOL_NAME}} dokumentiert. Die Bewertung umfasst Zweck und mögliche Folgen der Änderung, Auswirkungen auf Risiken und Maßnahmen, benötigte Ressourcen sowie die Zuweisung von Verantwortlichkeiten. Die Freigabe erfolgt durch {{ROLE_MANAGEMENT}}; technische Änderungen laufen zusätzlich über das Änderungsmanagement (BL-OPS-09, siehe {{LINK:VA-04}})."
},
"ISO-MS-DOKU": {
"titel": "Lenkung dokumentierter Information",
"umsetzung": "Die dokumentierte Information des ISMS wird im {{TOOL_NAME}} geführt. Jedes Dokument trägt Titel, eindeutige Kennung, Version, Datum, Status, verantwortliche Rolle und Freigebenden; Erstellung und Änderung durchlaufen Prüfung und Freigabe im Vier-Augen-Prinzip (BL-GOV-03). Die Lenkung stellt Verfügbarkeit für die berechtigten Rollen, Schutz vor unbefugter Änderung, gesteuerte Verteilung, Versionsführung mit Änderungsverlauf und die Aufbewahrung abgelöster Fassungen ({{RECORDS_RETENTION}}) sicher. Dokumente externer Herkunft werden gekennzeichnet und ebenso gelenkt. Der Prüfzyklus beträgt {{POLICY_REVIEW_CYCLE}}."
},
"ISO-KONTAKTE": {
"titel": "Kontakte zu Behörden und Interessengruppen",
"umsetzung": "{{ROLE_ISB}} pflegt eine Kontaktliste der relevanten Behörden und Meldestellen ({{AUTHORITY_CONTACTS}}) mit Zuständigkeit, Erreichbarkeit und Meldeweg; sie wird {{POLICY_REVIEW_CYCLE}} auf Aktualität geprüft und ist im Notfall auch ohne IT-Zugriff verfügbar. Meldepflichten und Fristen sind im Incident-Verfahren hinterlegt ({{LINK:VA-01}}). Zusätzlich werden fachliche Kontakte zu Interessengruppen, Fachforen und Sicherheitsverbänden gepflegt; die daraus gewonnenen Erkenntnisse fließen in die Bewertung von Bedrohungsinformationen ein."
},
"ISO-SOA": {
"titel": "Erklärung zur Anwendbarkeit (SoA)",
"umsetzung": "Aus der Risikobehandlung wird bestimmt, welche Maßnahmen erforderlich sind; das Ergebnis wird mit Anhang A abgeglichen, um übersehene Maßnahmen zu erkennen. Die Erklärung zur Anwendbarkeit wird im {{TOOL_NAME}} geführt und enthält je Control: Anwendbarkeit, Begründung der Einbeziehung, Herkunft (Risiko-ID, gesetzliche oder vertragliche Anforderung), Umsetzungsstatus, verantwortliche Rolle, Verweis auf Richtlinie und Verfahren sowie Nachweis; bei Ausschluss wird die Begründung dokumentiert. Der Risikobehandlungsplan und die Akzeptanz der verbleibenden Risiken werden von den jeweiligen Risikoeigentümern genehmigt; die SoA wird von {{ROLE_MANAGEMENT}} freigegeben und bei jeder Risikobeurteilung ({{RISK_REVIEW_CYCLE}}) aktualisiert."
},
"ISO-MS-BETRIEB": {
"titel": "Betriebliche Planung und Steuerung",
"umsetzung": "Die zur Erfüllung der Informationssicherheitsanforderungen erforderlichen Prozesse sind in den Verfahrensanweisungen festgelegt und werden im {{TOOL_NAME}} gesteuert; je Prozess sind Auslöser, verantwortliche Rolle, Fristen und Nachweise bestimmt. Geplante Änderungen werden gesteuert und ihre Folgen bewertet; unbeabsichtigte Änderungen werden überprüft und erforderlichenfalls korrigiert. Ausgelagerte Prozesse werden über die Lieferantensteuerung ({{LINK:R13}}) bestimmt und überwacht. Nachweise über die planmäßige Durchführung werden im Nachweisregister ({{LINK:NACHWEISREGISTER}}) geführt."
},
"ISO-MS-MESSUNG": {
"titel": "Überwachung, Messung, Analyse und Bewertung",
"umsetzung": "Für die Bewertung der Informationssicherheitsleistung und der Wirksamkeit des ISMS ist festgelegt, was gemessen wird (Kennzahlenblatt im {{TOOL_NAME}}), mit welcher Methode und Datenquelle, in welchem Takt gemessen wird, wer misst, wann die Ergebnisse ausgewertet werden und wer sie auswertet. Die Kennzahlen decken mindestens Vorfallbearbeitung, Schwachstellen- und Patchbehebung, Rezertifizierung von Berechtigungen, Wiederherstellungstests, Awareness-Teilnahme und offene Maßnahmen ab; je Kennzahl sind Zielwert und verantwortliche Rolle hinterlegt. Ergebnisse und Trends gehen {{MGMT_REVIEW_CYCLE}} in die Managementbewertung ein; eine Abweichung vom Zielwert löst eine Maßnahme aus."
},
"ISO-MS-MGMTREVIEW": {
"titel": "Managementbewertung",
"umsetzung": "{{ROLE_MANAGEMENT}} bewertet das ISMS mindestens {{MGMT_REVIEW_CYCLE}} anhand einer festen Tagesordnung (BL-GOV-02). Eingaben sind mindestens: Status der Maßnahmen aus früheren Bewertungen; Änderungen relevanter interner und externer Themen sowie der Anforderungen interessierter Parteien; Rückmeldungen zur Informationssicherheitsleistung (Nichtkonformitäten und Korrekturmaßnahmen, Überwachungs- und Messergebnisse, Auditergebnisse, Erreichung der Informationssicherheitsziele); Rückmeldungen interessierter Parteien; Ergebnisse der Risikobeurteilung und Status des Risikobehandlungsplans; Verbesserungsmöglichkeiten. Ergebnisse sind Entscheidungen zu Verbesserungsmöglichkeiten und zu Änderungsbedarf am ISMS, jeweils mit verantwortlicher Rolle und Termin. Das Protokoll wird im {{TOOL_NAME}} aufbewahrt."
},
"ISO-MS-CAPA": {
"titel": "Nichtkonformität, Korrekturmaßnahmen und fortlaufende Verbesserung",
"umsetzung": "Nichtkonformitäten aus Audits, Kontrollen, Vorfällen, Kennzahlenabweichungen und Hinweisen werden im {{TOOL_NAME}} erfasst. Je Fall werden die Sofortkorrektur und der Umgang mit den Folgen festgelegt, die Ursache analysiert und bewertet, ob gleichartige Nichtkonformitäten anderswo bestehen oder auftreten können. Erforderliche Korrekturmaßnahmen werden mit verantwortlicher Rolle und Termin umgesetzt; ihre Wirksamkeit wird nach Ablauf des festgelegten Wirksamkeitsintervalls bewertet und erforderlichenfalls werden Risiken, Maßnahmen und Dokumente angepasst. Art der Nichtkonformität, ergriffene Maßnahmen und Ergebnis der Wirksamkeitsbewertung werden aufbewahrt. Eignung, Angemessenheit und Wirksamkeit des ISMS werden fortlaufend verbessert; der Nachweis erfolgt über Kennzahlen und Managementbewertung."
},
"ISO-THREATINTEL": {
"titel": "Bedrohungsinformationen",
"umsetzung": "Informationen über Bedrohungen werden regelmäßig aus benannten Quellen ({{THREAT_INTEL_SOURCES}}) bezogen und von {{ROLE_IT_LEAD}} auf Relevanz für die eigenen Systeme und Dienste bewertet. Relevante Erkenntnisse führen zu Maßnahmen im Schwachstellen- und Patchmanagement ({{LINK:VA-06}}), zu Anpassungen der Überwachung ({{LINK:VA-13}}) oder zu einer erneuten Risikobeurteilung. Bewertung und abgeleitete Maßnahmen werden im {{TOOL_TICKET}} dokumentiert."
},
"ISO-BETRIEBSABLAEUFE": {
"titel": "Dokumentierte Betriebsabläufe",
"umsetzung": "Betriebsabläufe für informationsverarbeitende Einrichtungen sind dokumentiert und den ausführenden Personen zugänglich. Abgedeckt sind Inbetriebnahme und Konfiguration, Betrieb und Überwachung, Datensicherung, Behandlung von Störungen, Wartung sowie Außerbetriebnahme. Die Dokumentation wird bei Änderungen über das Änderungsmanagement (BL-OPS-09) aktualisiert und mindestens {{POLICY_REVIEW_CYCLE}} auf Aktualität geprüft. Verantwortlich: {{ROLE_IT_LEAD}}."
},
"ISO-KAPAZITAET": {
"titel": "Kapazitätssteuerung",
"umsetzung": "Die Auslastung der maßgeblichen Ressourcen — Rechenleistung, Arbeitsspeicher, Speicherplatz, Netzbandbreite, Lizenzen sowie personelle Kapazität im IT-Betrieb — wird {{CAPACITY_REVIEW_FREQ}} überwacht (BL-OPS-11). Überschrittene Schwellenwerte lösen eine Meldung aus; der künftige Bedarf wird bei Projekten und wesentlichen Änderungen berücksichtigt. Kapazitätsengpässe mit Auswirkung auf die Verfügbarkeitsanforderungen werden als Risiko erfasst und behandelt."
},
"ISO-DLP": {
"titel": "Verhinderung von Datenabfluss",
"umsetzung": "Für Systeme, Netze und Geräte, die schutzbedürftige Informationen verarbeiten, sind Maßnahmen gegen unbefugten Abfluss umgesetzt (BL-OPS-12); abgedeckt sind mindestens {{DLP_SCOPE}}. Die Maßnahmen richten sich nach der Klassifizierung ({{LINK:R02}}): Regeln zur Weitergabe, Kontrolle der Übertragungswege, Beschränkung von Wechseldatenträgern (BL-EP-03) sowie Protokollierung und Auswertung auffälliger Übertragungen (BL-OPS-04). Erkannte Verstöße werden als Sicherheitsereignis behandelt ({{LINK:VA-01}}); bei personenbezogener Auswertung werden Mitbestimmungsrechte gewahrt."
},
"ISO-ZEITSYNC": {
"titel": "Uhrzeitsynchronisation",
"umsetzung": "Die Systemuhren aller protokollierenden Systeme werden auf {{NTP_SOURCES}} synchronisiert (BL-OPS-10). Abweichungen werden überwacht und gemeldet. Eine einheitliche Zeitbasis und Zeitzone ist Voraussetzung für die Auswertbarkeit der Protokolle ({{LINK:VA-13}}) und für die Beweissicherung bei Vorfällen."
},
"ISO-DISZIPLIN": {
"titel": "Vorgehen bei Verstößen",
"umsetzung": "Für Verstöße gegen die Informationssicherheitsvorgaben besteht ein abgestuftes, dokumentiertes Vorgehen, das im Voraus kommuniziert ist. Es berücksichtigt Art und Schwere des Verstoßes, Vorsatz oder Fahrlässigkeit, Wiederholung sowie den Schulungsstand der betroffenen Person. Das Verfahren wird von {{ROLE_HR_LEAD}} in Abstimmung mit {{ROLE_ISB}} geführt; arbeitsrechtliche Vorgaben und Mitbestimmungsrechte werden gewahrt. Die Anwendung wird vertraulich dokumentiert."
},
"ISO-PHY-UMWELT": {
"titel": "Umgebungsschutz, Versorgung, Verkabelung und Wartung",
"umsetzung": "Standorte und technische Einrichtungen sind gegen physische und umweltbedingte Bedrohungen geschützt (BL-PHY-03): Brandfrüherkennung, Schutz gegen Wasser und Feuchtigkeit, Temperatur- und Feuchteüberwachung in Technikräumen sowie Berücksichtigung standortspezifischer Gefahren. Betriebsmittel sind so platziert, dass Einsicht, unbefugter Zugriff und Umgebungsrisiken minimiert werden. Strom- und Klimaversorgung sind für kritische Systeme unterbrechungsfrei ausgelegt und werden regelmäßig geprüft. Strom- und Datenverkabelung ist gegen Beschädigung und unbefugten Zugriff geschützt und dokumentiert. Betriebsmittel werden nach Herstellervorgabe gewartet; Wartungen erfolgen nur durch berechtigtes Personal, werden geplant und protokolliert und bei externer Durchführung begleitet."
},
"ISO-PHY-CLEARDESK": {
"titel": "Aufgeräumter Arbeitsplatz und Bildschirmsperre",
"umsetzung": "Es gelten verbindliche Regeln für einen aufgeräumten Arbeitsplatz und gesperrte Bildschirme (BL-PHY-04): Schutzbedürftige Unterlagen und Datenträger werden bei Abwesenheit verschlossen aufbewahrt; Bildschirme werden beim Verlassen des Arbeitsplatzes gesperrt und sperren automatisch nach {{SESSION_TIMEOUT}}. Ausdrucke werden unmittelbar entnommen, nicht mehr benötigte Unterlagen schutzbedarfsgerecht vernichtet (BL-DEL-01). Die Regeln gelten auch im Homeoffice und an mobilen Arbeitsplätzen ({{LINK:R06}}); die Einhaltung wird stichprobenartig geprüft."
},
"ISO-MASKIERUNG": {
"titel": "Datenmaskierung und Pseudonymisierung",
"umsetzung": "Wo der volle Informationsgehalt für den Verwendungszweck nicht erforderlich ist, werden Daten maskiert, pseudonymisiert oder anonymisiert. Das gilt insbesondere für Test-, Schulungs- und Entwicklungsumgebungen ({{LINK:R11}}), für Auswertungen sowie für Anzeigen mit eingeschränktem Zugriffsbedarf. Umfang und Verfahren richten sich nach der Klassifizierung und den Datenschutzanforderungen ({{LINK:R14}}); die Zulässigkeit einer Wiederherstellung des Personenbezugs und deren Absicherung sind geregelt."
}
}
}
seed/isms-vorlagenpaket-v2/_iso_sections_en.json
+81
View File
@@ -0,0 +1,81 @@
{
"hinweis": "English texts of the ISO-only sections. Individualisation exclusively via {{VARIABLES}} and baseline IDs (BL-*) — do not enter literal values.",
"abschnitte": {
"ISO-LEITLINIE": {
"titel": "Information security policy, objectives and communication",
"umsetzung": "This policy is approved by {{ROLE_MANAGEMENT}}, published in {{TOOL_NAME}} and made known to all staff and relevant third parties; acknowledgement is recorded per version. It is reviewed at least {{POLICY_REVIEW_CYCLE}} and upon significant change (BL-GOV-03). The thematic policies and the procedures elaborate it and follow the same approval and review cycle. The information security objectives are stated in measurable terms and held in {{TOOL_NAME}} with target value, responsible role and due date; their achievement is evaluated {{MGMT_REVIEW_CYCLE}}. For internal and external communication on information security it is defined what is communicated, when, with whom and by whom; the central point of contact is {{ROLE_ISB}}."
},
"ISO-MS-KONTEXT": {
"titel": "Context, interested parties and scope of the ISMS",
"umsetzung": "Internal and external issues as well as the relevant interested parties and their requirements are maintained in {{TOOL_NAME}} as a context and stakeholder analysis and updated at least {{POLICY_REVIEW_CYCLE}} and upon significant change. The scope of the ISMS ({{ISMS_SCOPE}}) is documented information and names sites, processes, organisational units and IT services as well as interfaces and dependencies on third parties; exclusions are justified. The ISMS is operated according to the PDCA cycle and continually improved. Responsible: {{ROLE_ISB}}; approval: {{ROLE_MANAGEMENT}}."
},
"ISO-MS-CHANGE": {
"titel": "Planning of changes to the ISMS",
"umsetzung": "Changes to the ISMS — scope, organisation, roles, key processes or systems — are planned, assessed before implementation and documented in {{TOOL_NAME}}. The assessment covers the purpose and potential consequences of the change, effects on risks and controls, the resources required and the assignment of responsibilities. Approval is given by {{ROLE_MANAGEMENT}}; technical changes additionally run through change management (BL-OPS-09, see {{LINK:VA-04}})."
},
"ISO-MS-DOKU": {
"titel": "Control of documented information",
"umsetzung": "The documented information of the ISMS is maintained in {{TOOL_NAME}}. Every document carries a title, a unique identifier, version, date, status, responsible role and approver; creation and modification pass through review and four-eyes approval (BL-GOV-03). Control ensures availability to the authorised roles, protection against unauthorised modification, managed distribution, version control with a change history and retention of superseded versions ({{RECORDS_RETENTION}}). Documents of external origin are identified and controlled in the same way. Review cycle: {{POLICY_REVIEW_CYCLE}}."
},
"ISO-KONTAKTE": {
"titel": "Contact with authorities and interest groups",
"umsetzung": "{{ROLE_ISB}} maintains a contact list of the relevant authorities and reporting bodies ({{AUTHORITY_CONTACTS}}) with responsibility, availability and reporting channel; it is checked for currency {{POLICY_REVIEW_CYCLE}} and is available in an emergency without IT access. Reporting obligations and deadlines are held in the incident procedure ({{LINK:VA-01}}). In addition, professional contacts with interest groups, forums and security associations are maintained; the resulting insights feed into the evaluation of threat intelligence."
},
"ISO-SOA": {
"titel": "Statement of Applicability (SoA)",
"umsetzung": "The risk treatment determines which controls are necessary; the result is compared against Annex A to identify controls that may have been overlooked. The Statement of Applicability is maintained in {{TOOL_NAME}} and states for each control: applicability, justification for inclusion, origin (risk ID, legal or contractual requirement), implementation status, responsible role, reference to policy and procedure as well as evidence; where a control is excluded, the justification is documented. The risk treatment plan and the acceptance of residual risks are approved by the respective risk owners; the SoA is approved by {{ROLE_MANAGEMENT}} and updated with every risk assessment ({{RISK_REVIEW_CYCLE}})."
},
"ISO-MS-BETRIEB": {
"titel": "Operational planning and control",
"umsetzung": "The processes required to meet the information security requirements are laid down in the procedures and controlled in {{TOOL_NAME}}; for each process the trigger, responsible role, deadlines and evidence are defined. Planned changes are controlled and their consequences assessed; unintended changes are reviewed and corrected where necessary. Outsourced processes are determined and monitored through supplier management ({{LINK:R13}}). Evidence of execution as planned is kept in the evidence register ({{LINK:NACHWEISREGISTER}})."
},
"ISO-MS-MESSUNG": {
"titel": "Monitoring, measurement, analysis and evaluation",
"umsetzung": "For the evaluation of information security performance and the effectiveness of the ISMS it is defined what is measured (metrics sheet in {{TOOL_NAME}}), by which method and data source, at which interval, who measures, when the results are analysed and who analyses them. The metrics cover at least incident handling, vulnerability and patch remediation, recertification of access rights, restore tests, awareness participation and open actions; each metric has a target value and a responsible role. Results and trends feed into the management review {{MGMT_REVIEW_CYCLE}}; a deviation from the target value triggers an action."
},
"ISO-MS-MGMTREVIEW": {
"titel": "Management review",
"umsetzung": "{{ROLE_MANAGEMENT}} reviews the ISMS at least {{MGMT_REVIEW_CYCLE}} against a fixed agenda (BL-GOV-02). Inputs are at least: status of actions from previous reviews; changes in relevant internal and external issues and in the requirements of interested parties; feedback on information security performance (nonconformities and corrective actions, monitoring and measurement results, audit results, achievement of the information security objectives); feedback from interested parties; results of the risk assessment and status of the risk treatment plan; opportunities for improvement. Outputs are decisions on opportunities for improvement and on any need to change the ISMS, each with a responsible role and a due date. The minutes are retained in {{TOOL_NAME}}."
},
"ISO-MS-CAPA": {
"titel": "Nonconformity, corrective action and continual improvement",
"umsetzung": "Nonconformities arising from audits, controls, incidents, deviations of metrics and reports are recorded in {{TOOL_NAME}}. For each case the immediate correction and the handling of the consequences are decided, the cause is analysed and it is evaluated whether similar nonconformities exist or could occur elsewhere. Necessary corrective actions are implemented with a responsible role and a due date; their effectiveness is evaluated after the defined effectiveness interval and, where necessary, risks, controls and documents are adjusted. The nature of the nonconformity, the actions taken and the result of the effectiveness review are retained. The suitability, adequacy and effectiveness of the ISMS are continually improved; evidence is provided through metrics and the management review."
},
"ISO-THREATINTEL": {
"titel": "Threat intelligence",
"umsetzung": "Information on threats is obtained regularly from named sources ({{THREAT_INTEL_SOURCES}}) and evaluated by {{ROLE_IT_LEAD}} for relevance to the organisation's own systems and services. Relevant findings lead to actions in vulnerability and patch management ({{LINK:VA-06}}), to adjustments of monitoring ({{LINK:VA-13}}) or to a new risk assessment. Evaluation and resulting actions are documented in {{TOOL_TICKET}}."
},
"ISO-BETRIEBSABLAEUFE": {
"titel": "Documented operating procedures",
"umsetzung": "Operating procedures for information processing facilities are documented and accessible to the personnel who carry them out. They cover commissioning and configuration, operation and monitoring, backup, handling of faults, maintenance and decommissioning. The documentation is updated through change management (BL-OPS-09) whenever changes occur and is checked for currency at least {{POLICY_REVIEW_CYCLE}}. Responsible: {{ROLE_IT_LEAD}}."
},
"ISO-KAPAZITAET": {
"titel": "Capacity management",
"umsetzung": "The utilisation of the relevant resources — compute, memory, storage, network bandwidth, licences and staffing in IT operations — is monitored {{CAPACITY_REVIEW_FREQ}} (BL-OPS-11). Exceeded thresholds raise an alert; future demand is taken into account in projects and significant changes. Capacity constraints that affect the availability requirements are recorded and treated as a risk."
},
"ISO-DLP": {
"titel": "Data leakage prevention",
"umsetzung": "For systems, networks and devices that process protected information, measures against unauthorised outflow are in place (BL-OPS-12); at least {{DLP_SCOPE}} are covered. The measures follow the classification ({{LINK:R02}}): rules for disclosure, control of transfer channels, restriction of removable media (BL-EP-03) as well as logging and analysis of conspicuous transfers (BL-OPS-04). Detected violations are handled as security events ({{LINK:VA-01}}); where analysis relates to individuals, co-determination rights are observed."
},
"ISO-ZEITSYNC": {
"titel": "Clock synchronisation",
"umsetzung": "The system clocks of all logging systems are synchronised to {{NTP_SOURCES}} (BL-OPS-10). Deviations are monitored and reported. A uniform time base and time zone is a prerequisite for the analysis of logs ({{LINK:VA-13}}) and for preserving evidence in the event of an incident."
},
"ISO-DISZIPLIN": {
"titel": "Handling of violations",
"umsetzung": "A graduated, documented process applies to violations of the information security requirements and is communicated in advance. It takes into account the nature and severity of the violation, intent or negligence, repetition and the training status of the person concerned. The process is run by {{ROLE_HR_LEAD}} in coordination with {{ROLE_ISB}}; employment law requirements and co-determination rights are observed. Its application is documented confidentially."
},
"ISO-PHY-UMWELT": {
"titel": "Environmental protection, utilities, cabling and maintenance",
"umsetzung": "Sites and technical facilities are protected against physical and environmental threats (BL-PHY-03): early fire detection, protection against water and moisture, temperature and humidity monitoring in technical rooms as well as consideration of site-specific hazards. Equipment is sited so that observation, unauthorised access and environmental risks are minimised. Power and air conditioning for critical systems are designed to be uninterruptible and are tested regularly. Power and data cabling is protected against damage and unauthorised access and is documented. Equipment is maintained according to the manufacturer's specifications; maintenance is carried out only by authorised personnel, is planned and recorded, and is supervised where performed externally."
},
"ISO-PHY-CLEARDESK": {
"titel": "Clear desk and screen lock",
"umsetzung": "Binding rules apply for a clear desk and locked screens (BL-PHY-04): protected documents and media are locked away when unattended; screens are locked when leaving the workplace and lock automatically after {{SESSION_TIMEOUT}}. Printouts are collected immediately and documents no longer required are destroyed according to their protection needs (BL-DEL-01). The rules also apply when working from home and at mobile workplaces ({{LINK:R06}}); compliance is checked on a sample basis."
},
"ISO-MASKIERUNG": {
"titel": "Data masking and pseudonymisation",
"umsetzung": "Where the full information content is not required for the purpose, data is masked, pseudonymised or anonymised. This applies in particular to test, training and development environments ({{LINK:R11}}), to analyses and to displays with a restricted need for access. Extent and method follow the classification and the data protection requirements ({{LINK:R14}}); whether the link to a person may be restored, and how that is safeguarded, is governed explicitly."
}
}
}
seed/isms-vorlagenpaket-v2/_iso_texts_en.json
+485
View File
@@ -0,0 +1,485 @@
{
"hinweis": "Englische Paraphrasen der ISO/IEC-27001:2022-Anforderungen (keine Normzitate). Struktur (Zuordnung, Bedingungen, Verfahren) kommt aus _iso_crosswalk.json.",
"texte": {
"4.1": {
"title": "Understanding the organisation and its context",
"requirement": "Internal and external issues that affect the ability to achieve the ISMS objectives are determined and kept up to date."
},
"4.2": {
"title": "Needs of interested parties",
"requirement": "The interested parties relevant to the ISMS and their information security requirements are determined."
},
"4.3": {
"title": "Scope of the ISMS",
"requirement": "The scope of the ISMS is determined considering the issues, requirements and interfaces, and maintained as documented information."
},
"4.4": {
"title": "Information security management system",
"requirement": "An ISMS is established, implemented, maintained and continually improved."
},
"5.1": {
"title": "Leadership and commitment",
"requirement": "Top management demonstrates leadership and commitment with respect to the ISMS."
},
"5.2": {
"title": "Information security policy",
"requirement": "An information security policy is established that fits the organisation, sets objectives, commits to meeting requirements and to continual improvement, and is communicated and available."
},
"5.3": {
"title": "Roles, responsibilities and authorities",
"requirement": "Responsibilities and authorities for security-relevant roles are assigned and communicated."
},
"6.1.1": {
"title": "Actions to address risks and opportunities",
"requirement": "When planning the ISMS, risks and opportunities that need to be addressed are determined."
},
"6.1.2": {
"title": "Information security risk assessment",
"requirement": "A risk assessment process with defined criteria is established and applied so that it is repeatable and produces comparable results."
},
"6.1.3": {
"title": "Information security risk treatment",
"requirement": "A risk treatment process is defined; necessary controls are determined and compared against Annex A in a Statement of Applicability."
},
"6.2": {
"title": "Information security objectives and planning",
"requirement": "Information security objectives are established for relevant functions and levels, and their achievement is planned."
},
"6.3": {
"title": "Planning of changes",
"requirement": "Changes to the ISMS are carried out in a planned manner."
},
"7.1": {
"title": "Resources",
"requirement": "The resources needed for the ISMS are determined and provided."
},
"7.2": {
"title": "Competence",
"requirement": "The necessary competence is determined and ensured; corresponding evidence is retained."
},
"7.3": {
"title": "Awareness",
"requirement": "Persons under the organisation's control are aware of the policy, their contribution and the consequences of non-conformance."
},
"7.4": {
"title": "Communication",
"requirement": "The internal and external communications relevant to the ISMS are determined."
},
"7.5.1": {
"title": "Documented information — general",
"requirement": "The ISMS includes the documented information required by the standard and that determined as necessary."
},
"7.5.2": {
"title": "Creating and updating",
"requirement": "When creating and updating documented information, identification, format and medium as well as review and approval are ensured."
},
"7.5.3": {
"title": "Control of documented information",
"requirement": "Documented information is controlled: availability, protection, distribution, access, retention and change control."
},
"8.1": {
"title": "Operational planning and control",
"requirement": "The processes needed to meet the requirements are planned, implemented and controlled; planned changes are controlled."
},
"8.2": {
"title": "Information security risk assessment (performance)",
"requirement": "Risk assessments are performed at planned intervals and upon significant change, and are documented."
},
"8.3": {
"title": "Information security risk treatment (performance)",
"requirement": "The risk treatment plan is implemented and the results are documented."
},
"9.1": {
"title": "Monitoring, measurement, analysis and evaluation",
"requirement": "The information security performance and the effectiveness of the ISMS are monitored, measured, analysed and evaluated."
},
"9.2": {
"title": "Internal audit",
"requirement": "Internal audits are conducted at planned intervals to verify conformity and effective implementation of the ISMS."
},
"9.3": {
"title": "Management review",
"requirement": "Top management reviews the ISMS at planned intervals."
},
"10.1": {
"title": "Continual improvement",
"requirement": "The suitability, adequacy and effectiveness of the ISMS are continually improved."
},
"10.2": {
"title": "Nonconformity and corrective action",
"requirement": "In the event of nonconformity, corrections are made and corrective actions are taken to eliminate the causes."
},
"A.5.1": {
"title": "Policies for information security",
"requirement": "The information security policy and topic-specific policies are defined, approved by management, published, communicated, acknowledged and reviewed at planned intervals."
},
"A.5.2": {
"title": "Information security roles and responsibilities",
"requirement": "Information security roles and responsibilities are defined and allocated."
},
"A.5.3": {
"title": "Segregation of duties",
"requirement": "Conflicting duties and areas of responsibility are segregated to reduce unauthorised or unintentional modification and misuse."
},
"A.5.4": {
"title": "Management responsibilities",
"requirement": "Management requires all personnel to apply information security in accordance with the established requirements."
},
"A.5.5": {
"title": "Contact with authorities",
"requirement": "Appropriate contacts with relevant authorities are established and maintained."
},
"A.5.6": {
"title": "Contact with special interest groups",
"requirement": "Appropriate contacts with special interest groups, professional forums and security associations are maintained."
},
"A.5.7": {
"title": "Threat intelligence",
"requirement": "Information on threats is collected and analysed to produce and use threat intelligence."
},
"A.5.8": {
"title": "Information security in project management",
"requirement": "Information security is integrated into project management."
},
"A.5.9": {
"title": "Inventory of information and other associated assets",
"requirement": "An inventory of information and associated assets, including owners, is established and maintained."
},
"A.5.10": {
"title": "Acceptable use of information and other associated assets",
"requirement": "Rules for the acceptable use and handling of information and assets are defined, documented and implemented."
},
"A.5.11": {
"title": "Return of assets",
"requirement": "Personnel and external users return all assets in their possession upon termination of employment or contract."
},
"A.5.12": {
"title": "Classification of information",
"requirement": "Information is classified according to its protection needs (confidentiality, integrity, availability)."
},
"A.5.13": {
"title": "Labelling of information",
"requirement": "Procedures for labelling information in accordance with the classification scheme are developed and implemented."
},
"A.5.14": {
"title": "Information transfer",
"requirement": "Rules, procedures and agreements for the secure transfer of information are established for all transfer channels in use."
},
"A.5.15": {
"title": "Access control",
"requirement": "Rules to control physical and logical access to information and assets are established and implemented on the basis of business and information security requirements."
},
"A.5.16": {
"title": "Identity management",
"requirement": "The full life cycle of identities is managed."
},
"A.5.17": {
"title": "Authentication information",
"requirement": "Allocation and management of authentication information is controlled by a suitable management process."
},
"A.5.18": {
"title": "Access rights",
"requirement": "Access rights are provisioned, reviewed, modified and removed in accordance with the access control policy."
},
"A.5.19": {
"title": "Information security in supplier relationships",
"requirement": "Processes to manage the information security risks arising from supplier relationships are defined and implemented."
},
"A.5.20": {
"title": "Addressing information security within supplier agreements",
"requirement": "Relevant information security requirements are agreed with each supplier and recorded contractually."
},
"A.5.21": {
"title": "Managing information security in the ICT supply chain",
"requirement": "Processes to manage information security risks in the ICT product and service supply chain are defined and implemented."
},
"A.5.22": {
"title": "Monitoring, review and change management of supplier services",
"requirement": "The information security of supplier services is monitored and reviewed regularly, and changes are managed."
},
"A.5.23": {
"title": "Information security for use of cloud services",
"requirement": "Processes for acquisition, use, management and exit of cloud services are established in line with the information security requirements."
},
"A.5.24": {
"title": "Information security incident management planning and preparation",
"requirement": "The management of information security incidents is planned and prepared (roles, processes, responsibilities)."
},
"A.5.25": {
"title": "Assessment and decision on information security events",
"requirement": "Information security events are assessed and a decision is taken whether they are to be categorised as incidents."
},
"A.5.26": {
"title": "Response to information security incidents",
"requirement": "Information security incidents are responded to in accordance with documented procedures."
},
"A.5.27": {
"title": "Learning from information security incidents",
"requirement": "Knowledge gained from information security incidents is used to strengthen the controls."
},
"A.5.28": {
"title": "Collection of evidence",
"requirement": "Procedures for the identification, collection, acquisition and preservation of evidence relating to incidents are established and implemented."
},
"A.5.29": {
"title": "Information security during disruption",
"requirement": "The maintenance of information security during disruption is planned and implemented."
},
"A.5.30": {
"title": "ICT readiness for business continuity",
"requirement": "ICT readiness is planned, implemented and tested on the basis of the business continuity objectives and requirements."
},
"A.5.31": {
"title": "Legal, statutory, regulatory and contractual requirements",
"requirement": "Legal, statutory, regulatory and contractual information security requirements are identified, documented and kept up to date."
},
"A.5.32": {
"title": "Intellectual property rights",
"requirement": "Appropriate procedures to protect intellectual property rights are implemented."
},
"A.5.33": {
"title": "Protection of records",
"requirement": "Records are protected against loss, destruction, falsification, unauthorised access and unauthorised release."
},
"A.5.34": {
"title": "Privacy and protection of PII",
"requirement": "Requirements for the protection of personally identifiable information are identified and met in accordance with applicable obligations."
},
"A.5.35": {
"title": "Independent review of information security",
"requirement": "The organisation's approach to managing information security is reviewed independently at planned intervals."
},
"A.5.36": {
"title": "Compliance with policies, rules and standards for information security",
"requirement": "Compliance with the information security policy, topic-specific policies, rules and standards is reviewed regularly."
},
"A.5.37": {
"title": "Documented operating procedures",
"requirement": "Operating procedures for information processing facilities are documented and made available to the personnel concerned."
},
"A.6.1": {
"title": "Screening",
"requirement": "Background verification of candidates is carried out appropriately to the business requirements and in accordance with the law."
},
"A.6.2": {
"title": "Terms and conditions of employment",
"requirement": "The employment agreements state the responsibilities for information security."
},
"A.6.3": {
"title": "Information security awareness, education and training",
"requirement": "Personnel receive appropriate awareness, education and training as well as regular updates of the relevant policies."
},
"A.6.4": {
"title": "Disciplinary process",
"requirement": "A disciplinary process for information security violations is established and communicated."
},
"A.6.5": {
"title": "Responsibilities after termination or change of employment",
"requirement": "Continuing information security responsibilities after termination or change of employment are defined and enforced."
},
"A.6.6": {
"title": "Confidentiality or non-disclosure agreements",
"requirement": "Confidentiality or non-disclosure agreements are identified, documented and reviewed regularly."
},
"A.6.7": {
"title": "Remote working",
"requirement": "Security measures for working outside the organisation's premises are implemented."
},
"A.6.8": {
"title": "Information security event reporting",
"requirement": "A mechanism for the timely reporting of observed or suspected information security events is provided."
},
"A.7.1": {
"title": "Physical security perimeters",
"requirement": "Security perimeters are defined and used to protect areas containing information and assets."
},
"A.7.2": {
"title": "Physical entry",
"requirement": "Secure entry controls and entry points are established to restrict access to authorised persons."
},
"A.7.3": {
"title": "Securing offices, rooms and facilities",
"requirement": "Physical security for offices, rooms and facilities is designed and implemented."
},
"A.7.4": {
"title": "Physical security monitoring",
"requirement": "Premises are continuously monitored for unauthorised physical access."
},
"A.7.5": {
"title": "Protecting against physical and environmental threats",
"requirement": "Protection against physical and environmental threats is designed and implemented."
},
"A.7.6": {
"title": "Working in secure areas",
"requirement": "Measures for working in secure areas are defined and implemented."
},
"A.7.7": {
"title": "Clear desk and clear screen",
"requirement": "Rules for a clear desk and locked screens are defined and implemented."
},
"A.7.8": {
"title": "Equipment siting and protection",
"requirement": "Equipment is sited securely and protected."
},
"A.7.9": {
"title": "Security of assets off-premises",
"requirement": "Assets used outside the premises are protected."
},
"A.7.10": {
"title": "Storage media",
"requirement": "Storage media are protected throughout their life cycle (acquisition, use, transport, disposal) in accordance with the classification scheme."
},
"A.7.11": {
"title": "Supporting utilities",
"requirement": "Facilities are protected against failure and disruption of supporting utilities such as power and air conditioning."
},
"A.7.12": {
"title": "Cabling security",
"requirement": "Power and data cabling is protected against interception, interference and damage."
},
"A.7.13": {
"title": "Equipment maintenance",
"requirement": "Equipment is maintained properly to ensure availability and integrity."
},
"A.7.14": {
"title": "Secure disposal or re-use of equipment",
"requirement": "Equipment containing storage media is securely sanitised before disposal or re-use."
},
"A.8.1": {
"title": "User endpoint devices",
"requirement": "Information stored on, processed by or accessible via user endpoint devices is protected."
},
"A.8.2": {
"title": "Privileged access rights",
"requirement": "The allocation and use of privileged access rights is restricted and closely managed."
},
"A.8.3": {
"title": "Information access restriction",
"requirement": "Access to information and application functions is restricted in accordance with the access control policy."
},
"A.8.4": {
"title": "Access to source code",
"requirement": "Read and write access to source code, development tools and software libraries is appropriately managed."
},
"A.8.5": {
"title": "Secure authentication",
"requirement": "Secure authentication technologies and procedures are used on the basis of the access restrictions and the access control policy."
},
"A.8.6": {
"title": "Capacity management",
"requirement": "Resources are monitored and capacity is adjusted to current and expected demand."
},
"A.8.7": {
"title": "Protection against malware",
"requirement": "Protection against malware is implemented and supported by appropriate user awareness."
},
"A.8.8": {
"title": "Management of technical vulnerabilities",
"requirement": "Information on technical vulnerabilities is obtained, exposure is evaluated and appropriate measures are taken."
},
"A.8.9": {
"title": "Configuration management",
"requirement": "Configurations of hardware, software, services and networks are established, documented, implemented, monitored and reviewed."
},
"A.8.10": {
"title": "Information deletion",
"requirement": "Information stored in systems and on media is deleted when no longer required."
},
"A.8.11": {
"title": "Data masking",
"requirement": "Data masking is applied in accordance with the access control and privacy requirements."
},
"A.8.12": {
"title": "Data leakage prevention",
"requirement": "Measures to prevent data leakage are applied to systems, networks and devices that process sensitive information."
},
"A.8.13": {
"title": "Information backup",
"requirement": "Backup copies of information, software and systems are created in accordance with the backup concept and tested regularly."
},
"A.8.14": {
"title": "Redundancy of information processing facilities",
"requirement": "Information processing facilities are implemented with sufficient redundancy to meet the availability requirements."
},
"A.8.15": {
"title": "Logging",
"requirement": "Logs of activities, exceptions, faults and events are produced, stored, protected and analysed."
},
"A.8.16": {
"title": "Monitoring activities",
"requirement": "Networks, systems and applications are monitored for anomalous behaviour and potential incidents are evaluated."
},
"A.8.17": {
"title": "Clock synchronisation",
"requirement": "System clocks are synchronised to approved time sources."
},
"A.8.18": {
"title": "Use of privileged utility programs",
"requirement": "The use of utility programs capable of overriding system and application controls is restricted and tightly controlled."
},
"A.8.19": {
"title": "Installation of software on operational systems",
"requirement": "Procedures and measures for securely managing software installation on operational systems are implemented."
},
"A.8.20": {
"title": "Networks security",
"requirement": "Networks and network devices are secured, managed and controlled to protect information."
},
"A.8.21": {
"title": "Security of network services",
"requirement": "Security mechanisms, service levels and requirements for network services are identified, implemented and monitored."
},
"A.8.22": {
"title": "Segregation of networks",
"requirement": "Groups of information services, users and systems are segregated in networks."
},
"A.8.23": {
"title": "Web filtering",
"requirement": "Access to external websites is managed to reduce exposure to malicious content."
},
"A.8.24": {
"title": "Use of cryptography",
"requirement": "Rules for the effective use of cryptography, including key management, are defined and implemented."
},
"A.8.25": {
"title": "Secure development life cycle",
"requirement": "Rules for a secure development life cycle of software and systems are established and applied."
},
"A.8.26": {
"title": "Application security requirements",
"requirement": "Information security requirements are identified, specified and taken into account when developing or acquiring applications."
},
"A.8.27": {
"title": "Secure system architecture and engineering principles",
"requirement": "Principles for engineering secure systems are established, documented and applied."
},
"A.8.28": {
"title": "Secure coding",
"requirement": "Secure coding principles are applied to software development."
},
"A.8.29": {
"title": "Security testing in development and acceptance",
"requirement": "Security testing is integrated into the development and acceptance process."
},
"A.8.30": {
"title": "Outsourced development",
"requirement": "Outsourced system development is directed, monitored and reviewed."
},
"A.8.31": {
"title": "Separation of development, test and production environments",
"requirement": "Development, test and production environments are separated and protected."
},
"A.8.32": {
"title": "Change management",
"requirement": "Changes to information processing facilities and systems are subject to change management."
},
"A.8.33": {
"title": "Test information",
"requirement": "Test information is selected, protected and managed with care."
},
"A.8.34": {
"title": "Protection of information systems during audit testing",
"requirement": "Audit tests and similar activities on operational systems are planned and agreed to avoid disruption."
}
}
}
seed/isms-vorlagenpaket-v2/_matrix.py
+36
View File
@@ -0,0 +1,36 @@
# -*- coding: utf-8 -*-
import json, collections, os
BASE=os.path.dirname(__file__)
d=json.load(open(os.path.join(BASE,"mapping.json"),encoding="utf-8"))
POLTITLE={"L00":"Informationssicherheitsleitlinie","R01":"ISMS-Organisation und Rollen","R02":"Asset- und Klassifizierung","R03":"Risikomanagement und Audit","R04":"Incident, Notfall und Kontinuität","R05":"Personalsicherheit und Awareness","R06":"Mobiles Arbeiten und mobile Geräte","R07":"Physische Sicherheit","R08":"Identitäts- und Zugriffsmanagement","R09":"Kryptografie und Übertragung","R10":"Betriebssicherheit","R11":"Sichere Beschaffung und Entwicklung","R12":"Cloud-, KI- und externe IT-Dienste","R13":"Lieferanten- und Dienstleistersteuerung","R14":"Compliance und Datenschutz"}
by=collections.OrderedDict()
for a in d["anforderungen"]:
by.setdefault(a["control"],[]).append(a)
def cnt(items,t): return sum(1 for x in items if x["type"]==t)
L=[]
L.append("# ISA-Mapping-Matrix - VDA ISA 2027 (Information Security)\n")
L.append("Zentrale Zuordnung **ISA-Control -> Richtlinie -> Einzelanforderungen** über alle Schutzbedarf-Ebenen (MUSS/SOLL/HOCH/SEHR HOCH). Anforderungen 1:1 aus der ISA übernommen; Kopplung über `mapping.json` und Hidden-Anker. Verweise: {{LINK:NACHWEISREGISTER}}, {{LINK:BASELINE}}.\n")
L.append("| ISA | Richtlinie | MUSS | SOLL | HOCH | SEHR HOCH | Verfahren |")
L.append("|-----|-----------|------|------|------|-----------|-----------|")
va_by_ctrl=collections.defaultdict(set)
for v in d.get("verfahren",[]):
for f in v["fulfills"]:
ctrl=f.rsplit("-",1)[0]
va_by_ctrl[ctrl].add(v["id"])
for ctrl,items in by.items():
pol=items[0]["policy"]
va=", ".join(sorted(va_by_ctrl.get(ctrl,[]))) or "-"
L.append(f"| {ctrl} | {{{{LINK:{pol}}}}} {POLTITLE.get(pol,pol)} | {cnt(items,'MUSS')} | {cnt(items,'SOLL')} | {cnt(items,'HOCH')} | {cnt(items,'SEHR HOCH')} | {va} |")
tot=collections.Counter(a["type"] for a in d["anforderungen"])
isa=sum(1 for a in d["anforderungen"] if a.get("is_isa"))
cust=sum(1 for a in d["anforderungen"] if not a.get("is_isa"))
L.append(f"\n**Summe:** {len(d['anforderungen'])} Anforderungen (MUSS {tot['MUSS']}, SOLL {tot['SOLL']}, HOCH {tot['HOCH']}, SEHR HOCH {tot['SEHR HOCH']}) — davon {isa} 1:1 aus VDA ISA und {cust} kundenspezifische Ergänzung (KI). Controls: {len(by)}.\n")
L.append("> 3.1.2 in ISA 2027 als 'Superseded by 1.6.3, 5.2.8 und 5.2.9' entfallen - abgedeckt über {{LINK:R04}} und {{LINK:R10}}.\n")
L.append("## Detailzuordnung je Anforderung\n")
L.append("| ID | Ebene | Richtlinie | Anforderung (Kurz) | Bedingung |")
L.append("|----|-------|-----------|--------------------|-----------|")
for a in d["anforderungen"]:
req=a["requirement"].replace("|","/"); req=(req[:90]+"...") if len(req)>90 else req
L.append(f"| {a['id']} | {a['type']} | {a['policy']} | {req} | {a['condition'] or '-'} |")
open(os.path.join(BASE,"ISA-Mapping-Matrix.md"),"w",encoding="utf-8").write("\n".join(L))
print("Matrix ok. Anforderungen:",len(d["anforderungen"]),"Controls:",len(by))
seed/isms-vorlagenpaket-v2/_render_diff.py
+79
View File
@@ -0,0 +1,79 @@
# -*- coding: utf-8 -*-
"""
Regressionsschutz: Rendert alle Richtlinien in einer Framework-Sicht und vergleicht das
Ergebnis mit einem Git-Stand. Erwartung fuer TISAX: 0 Abweichungen.
python3 _render_diff.py <git-revision> [--framework TISAX|ISO|BEIDE]
Beispiele:
python3 _render_diff.py a9649b3 # TISAX-Sicht gegen den Stand vor dem ISO-Umbau
python3 _render_diff.py dev --framework ISO # ISO-Sicht gegen dev
Verglichen wird der gerenderte Text ohne Leerzeilen und ohne Kommentar-Anker — also das,
was ein Mandant tatsaechlich zu sehen bekommt.
"""
import difflib, glob, json, os, re, subprocess, sys
BASE = os.path.dirname(os.path.abspath(__file__))
REPO = subprocess.run(["git", "rev-parse", "--show-toplevel"], cwd=BASE,
capture_output=True, text=True).stdout.strip()
if len(sys.argv) < 2:
print(__doc__); sys.exit(2)
REV = sys.argv[1]
FW = "TISAX"
if "--framework" in sys.argv:
FW = sys.argv[sys.argv.index("--framework") + 1].upper()
schema = json.load(open(os.path.join(BASE, "variables.schema.json"), encoding="utf-8"))
def ctx():
c = {k: (True if k.startswith("FLAG_") else "{%s}" % k) for k in schema["properties"]}
for k in ["FLAG_OT_USED", "FLAG_DEV_INHOUSE", "FLAG_CRYPTO_PKI", "FLAG_CUSTOMER_SYSTEMS"]:
c[k] = False
c["FLAG_FW_TISAX"] = FW in ("TISAX", "BEIDE")
c["FLAG_FW_ISO27001"] = FW in ("ISO", "BEIDE")
return c
def render(txt, c):
pat = re.compile(r"\{\{#if (\w+)\}\}((?:(?!\{\{#if )(?!\{\{/if\}\}).)*?)\{\{/if\}\}", re.S)
prev = None
while prev != txt:
prev = txt
txt = pat.sub(lambda m: (m.group(2) if c.get(m.group(1)) else ""), txt)
txt = re.sub(r"<!--.*?-->", "", txt, flags=re.S)
txt = re.sub(r"\{\{LINK:([^}]+)\}\}", r"[\1]", txt)
txt = re.sub(r"\{\{(\w+)\}\}", lambda m: str(c.get(m.group(1), "?")), txt)
return [l.rstrip() for l in txt.split("\n") if l.strip()]
def at_rev(relpath):
r = subprocess.run(["git", "show", "%s:%s" % (REV, relpath)], cwd=REPO,
capture_output=True, text=True)
return r.stdout if r.returncode == 0 else None
c = ctx()
drift, missing, checked = 0, 0, 0
for path in sorted(glob.glob(os.path.join(BASE, "richtlinien", "*.md"))):
rel = os.path.relpath(path, REPO)
old_raw = at_rev(rel)
if old_raw is None:
missing += 1
print(" neu in dieser Fassung:", os.path.basename(path))
continue
checked += 1
old, new = render(old_raw, c), render(open(path, encoding="utf-8").read(), c)
if old != new:
drift += 1
print("ABWEICHUNG:", os.path.basename(path))
for line in list(difflib.unified_diff(old, new, lineterm="", n=0))[:10]:
print(" ", line[:140])
print()
print("Sicht: %s · Vergleichsstand: %s" % (FW, REV))
print("geprueft: %d Richtlinien, neu: %d, abweichend: %d" % (checked, missing, drift))
print("OK" if drift == 0 else "PRUEFEN")
sys.exit(0 if drift == 0 else 1)
seed/isms-vorlagenpaket-v2/_verify.py
+62
View File
@@ -0,0 +1,62 @@
# -*- coding: utf-8 -*-
# Korrekter rekursiver {{#if}}-Renderer (wie echtes Handlebars) zur Verifikation.
import re, glob, json, os
BASE=os.path.dirname(__file__)
schema=json.load(open(os.path.join(BASE,"variables.schema.json")))
allvars=set(schema["properties"].keys())
def make_ctx(inc, extra=None):
c={k:(True if k.startswith("FLAG_") else k) for k in allvars}
for k in ["FLAG_OT_USED","FLAG_DEV_INHOUSE","FLAG_CRYPTO_PKI","FLAG_CUSTOMER_SYSTEMS"]: c[k]=False
c["FLAG_INCLUDE_SHOULD"]=inc
c["ORG_NAME"]="Muster GmbH"; c["TOOL_NAME"]="ISMS-Portal"; c["REVIEW_CYCLE"]="jährlich"
c["FLAG_FW_TISAX"]=True; c["FLAG_FW_ISO27001"]=False # dieses Skript prueft die TISAX-Sicht
if extra: c.update(extra)
return c
def render_if(t,c):
# rekursiv innerste Bloecke zuerst
pat=re.compile(r"\{\{#if (\w+)\}\}((?:(?!\{\{#if )(?!\{\{/if\}\}).)*?)\{\{/if\}\}",re.S)
prev=None
while prev!=t:
prev=t
t=pat.sub(lambda m:(m.group(2) if c.get(m.group(1)) else ""),t)
return t
def render(t,c):
t=render_if(t,c)
t=re.sub(r"\{\{LINK:[^}]+\}\}","[LINK]",t)
t=re.sub(r"\{\{(\w+)\}\}",lambda m:str(c[m.group(1)]) if m.group(1) in c else "«MISS:%s»"%m.group(1),t)
return t
files=sorted(glob.glob(os.path.join(BASE,"richtlinien/*.md")))+[os.path.join(BASE,"Nachweisregister_zentral.md"),os.path.join(BASE,"ISA-Mapping-Matrix.md")]
problems=0
for inc in [True,False]:
c=make_ctx(inc)
for fp in files:
r=render(open(fp,encoding="utf-8").read(),c)
bad=re.findall(r"\{\{.*?\}\}",r); miss=sorted(set(re.findall(r"«MISS:\w+»",r)))
if bad or miss:
problems+=1; print("!",os.path.basename(fp),"inc=%s"%inc,"open:",bad[:4],"miss:",miss[:4])
# Zwei Framework-Mappings teilen sich diese Bibliothek: die Anker des ISO-Mappings
# werden hier ausgeblendet und von _verify_iso.py geprueft.
iso_anchors=set()
_iso=os.path.join(BASE,"mapping-iso.json")
if os.path.exists(_iso):
for a in json.load(open(_iso,encoding="utf-8"))["anforderungen"]:
iso_anchors.add(a["req_anchor"]); iso_anchors.add(a["impl_anchor"])
d=json.load(open(os.path.join(BASE,"mapping.json")))
fa=set()
for fp in glob.glob(os.path.join(BASE,"richtlinien/*.md")):
for m in re.findall(r"<!-- (REQ|IMPL) ([0-9.\-A-Za-z]+) -->",open(fp,encoding="utf-8").read()): fa.add(m[0]+" "+m[1])
ma=set()
for a in d["anforderungen"]: ma.add(a["req_anchor"]); ma.add(a["impl_anchor"])
fa-=(iso_anchors-ma) # nur ISO-exklusive Anker ausblenden; gemeinsam genutzte bleiben geprueft
# F17: mapping.json enthaelt kein 'implementation'-Feld; der Umsetzungstext wird zur
# Laufzeit ueber impl_anchor (Control-IMPL-Block) aus der jeweiligen .md aufgeloest.
leftover_hb=any("{{" in a["requirement"] or "{{" in a.get("implementation","") for a in d["anforderungen"])
print("Render-Probleme:",problems)
print("mapping-Anker ohne Datei:",sorted(ma-fa))
print("Datei-Anker ohne mapping:",sorted(fa-ma))
print("Handlebars-Reste in mapping-Text:",leftover_hb)
print("OK" if problems==0 and not (ma-fa) and not (fa-ma) and not leftover_hb else "PRUEFEN")
seed/isms-vorlagenpaket-v2/_verify_iso.py
+138
View File
@@ -0,0 +1,138 @@
# -*- coding: utf-8 -*-
"""
Prueft die ISO/IEC-27001-Sicht der gemeinsamen Dokumentenbibliothek.
Gegenstueck zu _verify.py (das die TISAX-Sicht prueft). Geprueft wird:
1. Vollstaendigkeit — 27 Klauseln (Kap. 4-10) + 93 Anhang-A-Controls, keine Luecke, keine Dublette
2. Anker — jeder req_anchor/impl_anchor aus mapping-iso.json existiert in einer Datei
3. Umsetzungstext — jeder impl_anchor loest auf einen nicht leeren Umsetzungsblock auf
4. Rendering — ISO-Sicht (FLAG_FW_ISO27001=True, FLAG_FW_TISAX=False) bleibt ohne
offene Platzhalter; ebenso die TISAX-Sicht (Regressionsschutz)
5. Verfahren — jede im Mapping genannte VA existiert und listet die ID im FULFILLS-Header
Aufruf: python3 _verify_iso.py
"""
import re, glob, json, os, sys
BASE = os.path.dirname(os.path.abspath(__file__))
LANG = sys.argv[sys.argv.index("--lang") + 1] if "--lang" in sys.argv else "de"
# Dieselbe Prüfung gilt für beide Sprachfassungen; nur das Verzeichnis wechselt.
PKG = BASE if LANG == "de" else os.path.normpath(os.path.join(BASE, "..", "isms-vorlagenpaket-v2-en"))
schema = json.load(open(os.path.join(PKG, "variables.schema.json"), encoding="utf-8"))
allvars = set(schema["properties"].keys())
mapping = json.load(open(os.path.join(PKG, "mapping-iso.json"), encoding="utf-8"))
reqs = mapping["anforderungen"]
problems = []
def ctx(framework):
c = {k: (True if k.startswith("FLAG_") else k) for k in allvars}
for k in ["FLAG_OT_USED", "FLAG_DEV_INHOUSE", "FLAG_CRYPTO_PKI", "FLAG_CUSTOMER_SYSTEMS"]:
c[k] = False
c["ORG_NAME"] = "Muster GmbH"; c["TOOL_NAME"] = "ISMS-Portal"; c["REVIEW_CYCLE"] = "jährlich"
c["FLAG_FW_ISO27001"] = framework == "ISO"
c["FLAG_FW_TISAX"] = framework == "TISAX"
return c
def render(t, c):
pat_if = re.compile(r"\{\{#if (\w+)\}\}((?:(?!\{\{#if )(?!\{\{#unless )(?!\{\{/if\}\}).)*?)\{\{/if\}\}", re.S)
pat_un = re.compile(r"\{\{#unless (\w+)\}\}((?:(?!\{\{#unless )(?!\{\{/unless\}\}).)*?)\{\{/unless\}\}", re.S)
prev = None
while prev != t:
prev = t
t = pat_if.sub(lambda m: (m.group(2) if c.get(m.group(1)) else ""), t)
t = pat_un.sub(lambda m: ("" if c.get(m.group(1)) else m.group(2)), t)
t = re.sub(r"\{\{LINK:[^}]+\}\}", "[LINK]", t)
t = re.sub(r"\{\{(\w+)\}\}", lambda m: str(c[m.group(1)]) if m.group(1) in c else "«MISS:%s»" % m.group(1), t)
return t
# ── 1. Vollstaendigkeit ───────────────────────────────────────────────────────
clauses = [r["control"] for r in reqs if r["kind"] == "clause"]
controls = [r["control"] for r in reqs if r["kind"] != "clause"]
EXPECT = {"5": 37, "6": 8, "7": 14, "8": 34}
if len(clauses) != 27:
problems.append("Klausel-Anforderungen: %d statt 27" % len(clauses))
if len(controls) != 93:
problems.append("Anhang-A-Controls: %d statt 93" % len(controls))
for grp, n in EXPECT.items():
have = sorted(int(c.split(".")[2]) for c in controls if c.split(".")[1] == grp)
miss = [i for i in range(1, n + 1) if i not in have]
if miss:
problems.append("A.%s fehlt: %s" % (grp, miss))
if len(have) != len(set(have)):
problems.append("A.%s enthaelt Dubletten" % grp)
# ── 2./3. Anker und Umsetzungstext ────────────────────────────────────────────
impl_text, file_anchors = {}, set()
for fp in glob.glob(os.path.join(PKG, "richtlinien", "*.md")):
lines = open(fp, encoding="utf-8").read().split("\n")
for i, ln in enumerate(lines):
m = re.match(r"^<!--\s*(REQ|IMPL)\s+(\S+)\s*-->$", ln.strip())
if not m:
continue
file_anchors.add("%s %s" % (m.group(1), m.group(2)))
if m.group(1) == "IMPL":
buf = []
for l in lines[i + 1:]:
t = l.strip()
if t == "" or t.startswith("<!--") or t.startswith("{{#") or t.startswith("{{/") \
or re.match(r"^#{1,6}\s", t) or t.startswith("**") or t.startswith("- ") or t.startswith("|"):
break
buf.append(l)
impl_text[m.group(2)] = " ".join(buf).strip()
for r in reqs:
if r["req_anchor"] not in file_anchors:
problems.append("%s: req_anchor fehlt in den Dateien (%s)" % (r["control"], r["req_anchor"]))
key = r["impl_anchor"].replace("IMPL ", "")
if ("IMPL " + key) not in file_anchors:
problems.append("%s: impl_anchor fehlt in den Dateien (%s)" % (r["control"], r["impl_anchor"]))
elif not impl_text.get(key):
problems.append("%s: Umsetzungsblock %s ist leer" % (r["control"], r["impl_anchor"]))
# ── 4. Rendering beider Sichten ───────────────────────────────────────────────
files = sorted(glob.glob(os.path.join(PKG, "richtlinien", "*.md"))) + \
[os.path.join(PKG, "Technische-Sicherheits-Baseline.md"),
os.path.join(PKG, "Statement-of-Applicability-ISO.md")]
for fw in ["ISO", "TISAX"]:
c = ctx(fw)
for fp in files:
if not os.path.exists(fp):
continue
out = render(open(fp, encoding="utf-8").read(), c)
open_hb = re.findall(r"\{\{.*?\}\}", out)
miss = sorted(set(re.findall(r"«MISS:\w+»", out)))
if open_hb or miss:
problems.append("%s/%s: offen=%s fehlend=%s" % (fw, os.path.basename(fp), open_hb[:3], miss[:3]))
# ── 5. Verfahren ──────────────────────────────────────────────────────────────
va_fulfills = {}
for fp in glob.glob(os.path.join(PKG, "verfahren", "*.md")):
code = os.path.basename(fp).split("_")[0]
m = re.search(r"<!--\s*FULFILLS\s+([^|]+?)\s*\|\s*POLICY\s+(\S+)\s*-->", open(fp, encoding="utf-8").read())
va_fulfills[code] = [x.strip() for x in m.group(1).split(",")] if m else []
for r in reqs:
for va in r["verfahren"]:
if va not in va_fulfills:
problems.append("%s: Verfahren %s existiert nicht" % (r["control"], va))
elif r["id"] not in va_fulfills[va]:
problems.append("%s: %s fehlt im FULFILLS-Header von %s" % (r["control"], r["id"], va))
# ── Ergebnis ──────────────────────────────────────────────────────────────────
pol = {}
for r in reqs:
pol.setdefault(r["policy"], []).append(r["control"])
print("Sprache: %s" % LANG.upper())
print("Anforderungen: %d (%d Klauseln + %d Controls)" % (len(reqs), len(clauses), len(controls)))
print("Richtlinien: %s" % ", ".join("%s=%d" % (k, len(v)) for k, v in sorted(pol.items())))
print("Umsetzungsblöcke: %d referenziert, davon %d gemeinsam mit VDA ISA"
% (len({r["impl_anchor"] for r in reqs}),
len({r["impl_anchor"] for r in reqs if not r["impl_anchor"].startswith("IMPL ISO-")})))
print("Verfahren verknüpft:%d Anforderungen" % sum(1 for r in reqs if r["verfahren"]))
print("Befunde: %d" % len(problems))
for p in problems[:25]:
print(" !", p)
print("OK" if not problems else "PRUEFEN")
sys.exit(0 if not problems else 1)
seed/isms-vorlagenpaket-v2/mapping-iso.json
+2219
View File
File diff suppressed because it is too large Load Diff
seed/isms-vorlagenpaket-v2/mapping.json
+5351
View File
File diff suppressed because it is too large Load Diff
seed/isms-vorlagenpaket-v2/richtlinien/D01_Datenschutz.md
+49
View File
@@ -0,0 +1,49 @@
# Richtlinie Datenschutz
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_DPO}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt den Schutz personenbezogener Daten (Prüfziel Datenschutz, VDA ISA Kapitel 9). Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und ergänzt die Richtlinie Compliance und Datenschutz ({{LINK:R14}}).
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}), soweit personenbezogene Daten verarbeitet werden.
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA, Kapitel 9) und **Umsetzung bei {{ORG_NAME}}**.
{{#if FLAG_PERSONAL_DATA}}
### 3.1 Datenschutz-Organisation (ISA 9.1.1)
**Anforderung**
<!-- REQ 9.1.1-M1 -->
- **[MUSS]** Verantwortlichkeiten für den Datenschutz sind benannt und die Datenschutz-Organisation ist dokumentiert.
**Umsetzung bei {{ORG_NAME}}**
Die Rolle {{ROLE_DPO}} ist benannt und in die ISMS-Organisation eingebunden. Aufgaben, Meldewege und Eskalation sind dokumentiert.
### 3.2 Rechtmäßigkeit und Verarbeitungsverzeichnis (ISA 9.2.1)
**Anforderung**
<!-- REQ 9.2.1-M1 -->
- **[MUSS]** Verarbeitungen personenbezogener Daten sind rechtmäßig, zweckgebunden und in einem Verzeichnis der Verarbeitungstätigkeiten erfasst.
**Umsetzung bei {{ORG_NAME}}**
Ein Verzeichnis der Verarbeitungstätigkeiten wird geführt und regelmäßig aktualisiert. Für jede Verarbeitung sind Rechtsgrundlage, Zweck und Löschfristen dokumentiert.
{{/if}}
seed/isms-vorlagenpaket-v2/richtlinien/L00_Informationssicherheitsleitlinie.md
+175
View File
@@ -0,0 +1,175 @@
# Informationssicherheitsleitlinie
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Leitlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
<!-- REQ 1.1.1-M1 -->
Diese Informationssicherheitsleitlinie beschreibt die grundsätzlichen Anforderungen, Ziele und Verantwortlichkeiten der {{ORG_NAME}} zum Schutz von Informationen, IT-Systemen, Geschäftsprozessen und unterstützenden Werten. Die Anforderungen der Informationssicherheit sind bestimmt, dokumentiert und an den Zielen der {{ORG_NAME}} ausgerichtet.
Ziel ist es, ein angemessenes Informationssicherheitsniveau sicherzustellen und die Anforderungen des VDA ISA 2027 im Bereich Informationssicherheit zu erfüllen.
## 2. Geltungsbereich
Diese Leitlinie gilt für den definierten ISMS-Geltungsbereich:
{{ISMS_SCOPE_DESCRIPTION}}
Sie gilt für:
- alle Mitarbeitenden innerhalb des Geltungsbereichs,
- Führungskräfte,
- externe Dienstleister, soweit diese Zugriff auf Informationen, Systeme oder Prozesse der Organisation haben,
- relevante IT-Systeme, Informationen, Anwendungen, Standorte und Geschäftsprozesse innerhalb des ISMS-Scopes.
## 3. Ziele der Informationssicherheit
<!-- REQ 1.1.1-M3 -->
Die Leitlinie benennt die Ziele und die Bedeutung der Informationssicherheit. Die Organisation verfolgt mit dem ISMS insbesondere folgende Ziele:
- Schutz vertraulicher Informationen vor unbefugtem Zugriff,
- Sicherstellung der Integrität von Informationen und Systemen,
- Sicherstellung der Verfügbarkeit geschäftskritischer Informationen, Systeme und Services,
- Einhaltung gesetzlicher, regulatorischer und vertraglicher Anforderungen,
- angemessener Schutz von Kundeninformationen, personenbezogenen Daten, Geschäftsgeheimnissen und weiteren schutzbedürftigen Informationen,
- strukturierte Erkennung, Bewertung und Behandlung von Informationssicherheitsrisiken,
- kontinuierliche Verbesserung der Informationssicherheit.
## 4. Grundsätze der Informationssicherheit
Die Informationssicherheit basiert auf folgenden Grundsätzen:
### 4.1 Risikoorientierung
Informationssicherheitsmaßnahmen werden risikoorientiert geplant, umgesetzt, überprüft und verbessert. Risiken werden im eingesetzten ISMS-Tool ({{TOOL_NAME}}) bewertet und nachverfolgt (siehe {{LINK:R03}}).
### 4.2 Angemessenheit
Schutzmaßnahmen müssen dem Schutzbedarf der Informationen, Systeme und Prozesse angemessen sein. Dabei werden Vertraulichkeit, Integrität und Verfügbarkeit berücksichtigt.
### 4.3 Verantwortung
Informationssicherheit ist eine gemeinsame Verantwortung aller Mitarbeitenden. Die {{ROLE_MANAGEMENT}} trägt die Gesamtverantwortung für das ISMS.
### 4.4 Nachvollziehbarkeit
Entscheidungen, Bewertungen, Freigaben und wesentliche Maßnahmen im Zusammenhang mit Informationssicherheit sind nachvollziehbar zu dokumentieren.
### 4.5 Kontinuierliche Verbesserung
Das ISMS wird regelmäßig überprüft und bei Bedarf angepasst. Erkenntnisse aus Audits, Vorfällen, Risiken, Änderungen und Managementbewertungen fließen in die Verbesserung ein.
## 5. Informationssicherheitsanforderungen
<!-- REQ 1.1.1-S1 -->
{{#if FLAG_INCLUDE_SHOULD}}Die Informationssicherheitsanforderungen basieren auf der Strategie der {{ORG_NAME}}; gesetzliche und vertragliche Vorgaben werden berücksichtigt. {{/if}}Die Organisation bestimmt und dokumentiert Informationssicherheitsanforderungen auf Basis von:
- gesetzlichen und regulatorischen Anforderungen,
- vertraglichen Anforderungen, insbesondere von Kunden und Partnern,
- Anforderungen aus dem VDA ISA,
- internen Geschäftsanforderungen,
- Ergebnissen aus Risikoanalysen,
- Schutzbedarf von Informationen, Prozessen und IT-Systemen,
- Anforderungen aus Projekten, Änderungen und externen IT-Services.
Die jeweils relevanten Anforderungen werden im ISMS berücksichtigt und über geeignete Richtlinien, Prozesse, technische Maßnahmen und Nachweise umgesetzt.
## 6. Rollen und Verantwortlichkeiten
Die Organisation definiert Rollen und Verantwortlichkeiten für Informationssicherheit. Dazu gehören mindestens:
| Rolle | Grundsätzliche Verantwortung |
|-------|------------------------------|
| {{ROLE_MANAGEMENT}} | Gesamtverantwortung, Freigabe der Informationssicherheitsleitlinie, Bereitstellung angemessener Ressourcen |
| {{ROLE_ISB}} | Steuerung, Pflege und Weiterentwicklung des ISMS |
| Führungskräfte | Umsetzung der Anforderungen im jeweiligen Verantwortungsbereich |
| {{ROLE_IT_LEAD}} | Umsetzung technischer und organisatorischer Sicherheitsmaßnahmen im IT-Bereich |
| Asset Owner / Prozessverantwortliche | Bewertung und Pflege relevanter Informationen, Prozesse und Assets im ISMS-Tool |
| Mitarbeitende | Einhaltung der Richtlinien und Meldung von Sicherheitsereignissen |
| Externe Dienstleister | Einhaltung vertraglich vereinbarter Sicherheitsanforderungen |
Die konkrete Rollen- und Verantwortlichkeitszuordnung wird im ISMS-Tool ({{TOOL_NAME}}) oder in einer ergänzenden Rollenmatrix gepflegt (siehe auch {{LINK:R01}}).
## 7. Verbindlichkeit
<!-- REQ 1.1.1-M2 -->
<!-- REQ 1.1.1-S2 -->
Diese Leitlinie ist durch die {{ROLE_MANAGEMENT}} genehmigt und für alle betroffenen Personen im Geltungsbereich verbindlich. {{#if FLAG_INCLUDE_SHOULD}}Verstöße gegen Informationssicherheitsanforderungen können zu organisatorischen, arbeitsrechtlichen oder vertraglichen Maßnahmen führen. {{/if}}Alle Mitarbeitenden sind verpflichtet:
- die geltenden Informationssicherheitsrichtlinien einzuhalten,
- schutzbedürftige Informationen angemessen zu behandeln,
- Sicherheitsereignisse oder Verdachtsfälle unverzüglich zu melden,
- nur freigegebene Systeme, Anwendungen und Dienste zu nutzen,
- erkannte Schwachstellen oder Risiken an die zuständige Stelle zu melden.
## 8. Veröffentlichung und Kommunikation
<!-- REQ 1.1.1-M4 -->
<!-- REQ 1.1.1-M5 -->
Die Informationssicherheitsleitlinie wird den relevanten Personen in geeigneter Form bekannt gemacht; über relevante Änderungen werden Mitarbeitende und betroffene externe Partner informiert. Dies kann erfolgen über:
- Veröffentlichung im ISMS-Tool ({{TOOL_NAME}}),
- internes Wiki oder Dokumentenmanagementsystem,
- Onboarding-Prozess,
- Awareness-Schulungen (siehe {{LINK:R05}}),
- direkte Kommunikation an betroffene Zielgruppen.
## 9. Überprüfung und Aktualisierung
<!-- REQ 1.1.1-S4 -->
Diese Leitlinie wird regelmäßig überprüft, mindestens jedoch:
- {{REVIEW_CYCLE}},
- bei wesentlichen Änderungen des ISMS-Geltungsbereichs,
- bei wesentlichen organisatorischen oder technischen Änderungen,
- bei relevanten Sicherheitsvorfällen,
- bei neuen oder geänderten regulatorischen, gesetzlichen oder vertraglichen Anforderungen.
Änderungen werden dokumentiert und durch die {{ROLE_MANAGEMENT}} genehmigt.
## 10. Nachweise
Die Nachweise zur Umsetzung dieser Leitlinie werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 11. Verwandte Dokumente
<!-- REQ 1.1.1-S3 -->
Weitere themenspezifische Sicherheitsrichtlinien (R01–R14) sind etabliert und aufeinander abgestimmt.
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- ISMS-Organisation und Rollen: {{LINK:R01}}
- Alle thematischen Richtlinien: {{LINK:R01}} … {{LINK:R14}}
<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool über die Hidden-Anker aufgelöst. Im Lesemodus nicht sichtbar. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
## Anhang A — Informationssicherheitspolitik, Ziele und Kommunikation
*Anforderungsbezug:* ISO/IEC 27001 5.2, 6.2, 7.4, A.5.1
**Anforderung**
<!-- REQ 5.2-1 -->
- **[ISO 5.2]** Die oberste Leitung hat eine Informationssicherheitspolitik festzulegen, die zum Zweck der Organisation passt und Ziele bzw. einen Rahmen dafür enthält.
<!-- REQ 6.2-1 -->
- **[ISO 6.2]** Informationssicherheitsziele sind für relevante Funktionen und Ebenen festzulegen und deren Erreichung zu planen.
<!-- REQ 7.4-1 -->
- **[ISO 7.4]** Die für das ISMS relevante interne und externe Kommunikation ist zu bestimmen.
<!-- REQ A.5.1-1 -->
- **[ISO A.5.1]** Ein Satz von Informationssicherheitsrichtlinien ist zu definieren, von der Leitung zu genehmigen, zu veröffentlichen, zu kommunizieren und regelmäßig sowie anlassbezogen zu überprüfen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-LEITLINIE -->
Diese Leitlinie wird von der {{ROLE_MANAGEMENT}} freigegeben, im {{TOOL_NAME}} veröffentlicht und allen Beschäftigten sowie relevanten Dritten bekannt gemacht; die Kenntnisnahme wird je Fassung dokumentiert. Die Überprüfung erfolgt mindestens {{POLICY_REVIEW_CYCLE}} sowie bei wesentlichen Änderungen (BL-GOV-03). Die themenspezifischen Richtlinien und die Verfahrensanweisungen konkretisieren sie und durchlaufen denselben Freigabe- und Prüfzyklus. Die Informationssicherheitsziele sind messbar formuliert und mit Zielwert, verantwortlicher Rolle und Termin im {{TOOL_NAME}} hinterlegt; ihre Erreichung wird {{MGMT_REVIEW_CYCLE}} bewertet. Für die interne und externe Kommunikation zur Informationssicherheit ist festgelegt, worüber, wann, mit wem und durch wen kommuniziert wird; zentraler Ansprechpartner ist {{ROLE_ISB}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
seed/isms-vorlagenpaket-v2/richtlinien/P01_Prototypenschutz.md
+60
View File
@@ -0,0 +1,60 @@
# Richtlinie Prototypenschutz
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt den Schutz von Prototypen und schutzbedürftigen Entwicklungsobjekten (Prüfziel Prototypenschutz, VDA ISA Kapitel 8). Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und wird durch das Verfahren {{LINK:VA-20}} operationalisiert.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}), soweit Prototypen bzw. schutzbedürftige Entwicklungsobjekte verarbeitet, gelagert oder transportiert werden.
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA, Kapitel 8) und **Umsetzung bei {{ORG_NAME}}**.
{{#if FLAG_PROTOTYPE_PROTECTION}}
### 3.1 Physische Sicherheit und Perimeter (ISA 8.1.1)
**Anforderung**
<!-- REQ 8.1.1-M1 -->
- **[MUSS]** Bereiche, in denen Prototypen verarbeitet oder gelagert werden, sind durch definierte Sicherheitszonen und einen wirksamen Perimeter geschützt.
**Umsetzung bei {{ORG_NAME}}**
Prototypenbereiche sind als eigene Sicherheitszone mit Zutrittskontrolle, Perimeterschutz und Protokollierung ausgewiesen. Der Zutritt ist auf berechtigte Personen beschränkt.
### 3.2 Geheimhaltung und Klassifizierung (ISA 8.2.1)
**Anforderung**
<!-- REQ 8.2.1-M1 -->
- **[MUSS]** Für Prototypen bestehen Geheimhaltungsverpflichtungen; die zugehörigen Informationen sind klassifiziert und entsprechend gekennzeichnet.
**Umsetzung bei {{ORG_NAME}}**
Alle mit Prototypen befassten Personen (intern und extern) unterzeichnen Geheimhaltungsvereinbarungen. Prototypen und zugehörige Unterlagen werden gemäß Klassifizierungsschema als vertraulich oder höher eingestuft.
### 3.3 Transport und Lagerung (ISA 8.3.1)
**Anforderung**
<!-- REQ 8.3.1-M1 -->
- **[MUSS]** Transport und Lagerung von Prototypen erfolgen nach dokumentierten Schutzvorgaben, die Vertraulichkeit und Integrität sicherstellen.
**Umsetzung bei {{ORG_NAME}}**
Transport und Lagerung folgen dem Verfahren {{LINK:VA-20}}: abgesicherte Behältnisse, protokollierte Übergaben, Zutritts- und Sichtschutz sowie Nachverfolgbarkeit.
{{/if}}
seed/isms-vorlagenpaket-v2/richtlinien/R01_ISMS-Organisation-und-Rollen.md
+294
View File
@@ -0,0 +1,294 @@
# Richtlinie ISMS-Organisation und Rollen
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Aufbau, Steuerung und Verantwortlichkeiten des ISMS der {{ORG_NAME}} sowie die Berücksichtigung der Informationssicherheit in Projekten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Steuerung der Informationssicherheit
<!-- FW:REF-START ORIG:(ISA 1.2.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 5.1, A.5.4{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.1-M1 -->
- **[MUSS]** Der Geltungsbereich des ISMS (die durch das ISMS gesteuerte Organisation) ist definiert.
<!-- REQ 1.2.1-M2 -->
- **[MUSS]** Die Anforderungen der Organisation an das ISMS sind bestimmt.
<!-- REQ 1.2.1-M3 -->
- **[MUSS]** Die Organisationsleitung hat das ISMS beauftragt und genehmigt.
<!-- REQ 1.2.1-M4 -->
- **[MUSS]** Das ISMS stellt der Organisationsleitung geeignete Mittel zur Überwachung und Steuerung bereit (z. B. Managementbewertung).
<!-- REQ 1.2.1-M5 -->
- **[MUSS]** Die anwendbaren Controls sind bestimmt (z. B. ISO-27001-Anwendbarkeitserklärung oder ausgefüllter ISA-Katalog).
<!-- REQ 1.2.1-M6 -->
- **[MUSS]** Die Wirksamkeit des ISMS wird regelmäßig durch die Leitung überprüft.
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 5.1-1 -->
- **[ISO 5.1]** Die oberste Leitung hat Führung und Verpflichtung in Bezug auf das ISMS nachzuweisen.
<!-- REQ A.5.4-1 -->
- **[ISO A.5.4]** Die Leitung hat von allen Beschäftigten die Anwendung der Informationssicherheit gemäß den festgelegten Vorgaben einzufordern.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.2.1 -->
Der ISMS-Geltungsbereich, die Anforderungen und die anwendbaren Controls (Anwendbarkeitserklärung/ISA-Katalog) sind im ISMS-Tool ({{TOOL_NAME}}) dokumentiert. Die {{ROLE_MANAGEMENT}} hat das ISMS per Managementbeschluss beauftragt und genehmigt, stellt Ressourcen bereit und überprüft die Wirksamkeit mindestens {{REVIEW_CYCLE}} in einer dokumentierten Managementbewertung; die operative Steuerung liegt bei {{ROLE_ISB}}.
### 3.2 Organisation der Informationssicherheit
<!-- FW:REF-START ORIG:(ISA 1.2.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 5.3, 7.1, A.5.2, A.5.3{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.2-M1 -->
- **[MUSS]** Verantwortlichkeiten für Informationssicherheit sind definiert, dokumentiert und zugewiesen.
<!-- REQ 1.2.2-M2 -->
- **[MUSS]** Die verantwortlichen Beschäftigten sind definiert, qualifiziert und für ihre Aufgabe befähigt.
<!-- REQ 1.2.2-M3 -->
- **[MUSS]** Die erforderlichen Ressourcen stehen zur Verfügung.
<!-- REQ 1.2.2-M4 -->
- **[MUSS]** Die Ansprechpartner sind innerhalb der Organisation und relevanten Geschäftspartnern bekannt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.2-S1 -->
- **[SOLL]** Es besteht eine Definition und Dokumentation einer angemessenen Informationssicherheitsstruktur innerhalb der Organisation.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.2-S2 -->
- **[SOLL]** Sicherheitsrelevante Rollen, die nicht Teil des ISMS, aber für die Informationssicherheit relevant sind, werden berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.2.2-H1 -->
- **[HOCH]** Eine angemessene organisatorische Trennung von Verantwortlichkeiten ist etabliert, um Interessenkonflikte zu vermeiden (Funktionstrennung). (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 5.3-1 -->
- **[ISO 5.3]** Verantwortlichkeiten und Befugnisse für sicherheitsrelevante Rollen sind zuzuweisen und bekannt zu machen.
<!-- REQ 7.1-1 -->
- **[ISO 7.1]** Die für das ISMS erforderlichen Ressourcen sind zu bestimmen und bereitzustellen.
<!-- REQ A.5.2-1 -->
- **[ISO A.5.2]** Rollen und Verantwortlichkeiten für die Informationssicherheit sind zu definieren und zuzuweisen.
<!-- REQ A.5.3-1 -->
- **[ISO A.5.3]** Widerstreitende Aufgaben und Verantwortungsbereiche sind zu trennen, um unbefugte oder unbeabsichtigte Änderungen und Missbrauch zu reduzieren.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.2.2 -->
Die Verantwortlichkeiten sind in der Rollen-/Verantwortungsmatrix und im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und den Rolleninhabern sowie relevanten Geschäftspartnern bekannt gemacht. Die Rolle {{ROLE_ISB}} ist benannt, qualifiziert, mit Ressourcen und Weisungsrechten ausgestattet und berichtet direkt an die {{ROLE_MANAGEMENT}}.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.2.2-elev -->
Bei hohem Schutzbedarf ist eine organisatorische Funktionstrennung (z. B. Umsetzung vs. Kontrolle) etabliert; unvermeidbare Doppelrollen werden durch kompensierende Kontrollen (Vier-Augen-Prinzip) abgesichert.
{{/if}}
### 3.3 Informationssicherheit in Projekten
<!-- FW:REF-START ORIG:(ISA 1.2.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.2.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.8{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.2.3-M1 -->
- **[MUSS]** Projekte werden unter Berücksichtigung der Informationssicherheitsanforderungen klassifiziert.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S1 -->
- **[SOLL]** Verfahren und Kriterien für die Klassifizierung von Projekten sind dokumentiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S2 -->
- **[SOLL]** In einer frühen Projektphase wird eine Risikobewertung nach dem definierten Verfahren durchgeführt und bei Projektänderungen wiederholt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.2.3-S3 -->
- **[SOLL]** Für identifizierte Informationssicherheitsrisiken werden Maßnahmen abgeleitet und im Projekt berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.2.3-H1 -->
- **[HOCH]** Die abgeleiteten Maßnahmen werden während des Projekts regelmäßig überprüft und bei Änderungen der Bewertungskriterien neu bewertet. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.8-1 -->
- **[ISO A.5.8]** Informationssicherheit ist in das Projektmanagement zu integrieren.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.2.3 -->
Projekte werden zu Beginn anhand des dokumentierten Kriterienkatalogs (BL-PROJ-01) hinsichtlich Informationssicherheitsbedarf klassifiziert; Einstufung, Risikobewertung und abgeleitete Maßnahmen werden im Projektregister ({{LINK:REG-PROJECTS}}) geführt. In einer frühen Projektphase und bei Änderungen erfolgt eine Risikobewertung nach dem Verfahren Informationssicherheit in Projekten ({{LINK:VA-19}}); Maßnahmen werden als Aufgaben im {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft. Verantwortlich ist die Projektleitung; bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.2.3-elev -->
Bei hohem Schutzbedarf werden die abgeleiteten Maßnahmen fortlaufend im Projektverlauf überprüft und bei geänderten Bewertungskriterien neu bewertet.
{{/if}}
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Kontext, interessierte Parteien und Anwendungsbereich des ISMS
*Anforderungsbezug:* ISO/IEC 27001 4.1, 4.2, 4.3, 4.4
**Anforderung**
<!-- REQ 4.1-1 -->
- **[ISO 4.1]** Interne und externe Themen, die die Fähigkeit zur Erreichung der ISMS-Ziele beeinflussen, sind zu bestimmen und aktuell zu halten.
<!-- REQ 4.2-1 -->
- **[ISO 4.2]** Die für das ISMS relevanten interessierten Parteien und deren Anforderungen an die Informationssicherheit sind zu ermitteln.
<!-- REQ 4.3-1 -->
- **[ISO 4.3]** Der Anwendungsbereich des ISMS ist unter Berücksichtigung der Themen, Anforderungen und Schnittstellen festzulegen und als dokumentierte Information zu führen.
<!-- REQ 4.4-1 -->
- **[ISO 4.4]** Ein ISMS ist einzurichten, umzusetzen, aufrechtzuerhalten und fortlaufend zu verbessern.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-KONTEXT -->
Interne und externe Themen sowie die relevanten interessierten Parteien und deren Anforderungen werden im {{TOOL_NAME}} als Kontext- und Stakeholderanalyse geführt und mindestens {{POLICY_REVIEW_CYCLE}} sowie bei wesentlichen Änderungen aktualisiert. Der Anwendungsbereich des ISMS ({{ISMS_SCOPE}}) ist als dokumentierte Information festgelegt und benennt Standorte, Prozesse, Organisationseinheiten und IT-Dienste sowie Schnittstellen und Abhängigkeiten zu Dritten; Ausschlüsse werden begründet. Das ISMS wird nach dem PDCA-Zyklus betrieben und fortlaufend verbessert. Verantwortlich: {{ROLE_ISB}}; Freigabe: {{ROLE_MANAGEMENT}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Planung von Änderungen am ISMS
*Anforderungsbezug:* ISO/IEC 27001 6.3
**Anforderung**
<!-- REQ 6.3-1 -->
- **[ISO 6.3]** Änderungen am ISMS sind geplant durchzuführen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-CHANGE -->
Änderungen am ISMS — Anwendungsbereich, Organisation, Rollen, wesentliche Prozesse oder Systeme — werden geplant, vor der Umsetzung bewertet und im {{TOOL_NAME}} dokumentiert. Die Bewertung umfasst Zweck und mögliche Folgen der Änderung, Auswirkungen auf Risiken und Maßnahmen, benötigte Ressourcen sowie die Zuweisung von Verantwortlichkeiten. Die Freigabe erfolgt durch {{ROLE_MANAGEMENT}}; technische Änderungen laufen zusätzlich über das Änderungsmanagement (BL-OPS-09, siehe {{LINK:VA-04}}).
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.6 Lenkung dokumentierter Information
*Anforderungsbezug:* ISO/IEC 27001 7.5.1, 7.5.2, 7.5.3
**Anforderung**
<!-- REQ 7.5.1-1 -->
- **[ISO 7.5.1]** Das ISMS muss die von der Norm geforderte und die als notwendig bestimmte dokumentierte Information enthalten.
<!-- REQ 7.5.2-1 -->
- **[ISO 7.5.2]** Bei Erstellung und Aktualisierung dokumentierter Information sind Kennzeichnung, Format/Medium und Prüfung/Freigabe sicherzustellen.
<!-- REQ 7.5.3-1 -->
- **[ISO 7.5.3]** Dokumentierte Information ist zu lenken (Verfügbarkeit, Schutz, Verteilung, Zugriff, Aufbewahrung, Änderungssteuerung).
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-DOKU -->
Die dokumentierte Information des ISMS wird im {{TOOL_NAME}} geführt. Jedes Dokument trägt Titel, eindeutige Kennung, Version, Datum, Status, verantwortliche Rolle und Freigebenden; Erstellung und Änderung durchlaufen Prüfung und Freigabe im Vier-Augen-Prinzip (BL-GOV-03). Die Lenkung stellt Verfügbarkeit für die berechtigten Rollen, Schutz vor unbefugter Änderung, gesteuerte Verteilung, Versionsführung mit Änderungsverlauf und die Aufbewahrung abgelöster Fassungen ({{RECORDS_RETENTION}}) sicher. Dokumente externer Herkunft werden gekennzeichnet und ebenso gelenkt. Der Prüfzyklus beträgt {{POLICY_REVIEW_CYCLE}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.7 Kontakte zu Behörden und Interessengruppen
*Anforderungsbezug:* ISO/IEC 27001 A.5.5, A.5.6
**Anforderung**
<!-- REQ A.5.5-1 -->
- **[ISO A.5.5]** Angemessene Kontakte zu relevanten Behörden sind einzurichten und zu pflegen.
<!-- REQ A.5.6-1 -->
- **[ISO A.5.6]** Angemessene Kontakte zu speziellen Interessengruppen, Fachforen und Sicherheitsverbänden sind zu pflegen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-KONTAKTE -->
{{ROLE_ISB}} pflegt eine Kontaktliste der relevanten Behörden und Meldestellen ({{AUTHORITY_CONTACTS}}) mit Zuständigkeit, Erreichbarkeit und Meldeweg; sie wird {{POLICY_REVIEW_CYCLE}} auf Aktualität geprüft und ist im Notfall auch ohne IT-Zugriff verfügbar. Meldepflichten und Fristen sind im Incident-Verfahren hinterlegt ({{LINK:VA-01}}). Zusätzlich werden fachliche Kontakte zu Interessengruppen, Fachforen und Sicherheitsverbänden gepflegt; die daraus gewonnenen Erkenntnisse fließen in die Bewertung von Bedrohungsinformationen ein.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_MANAGEMENT}} | Beauftragung, Gesamtverantwortung, Managementbewertung |
| {{ROLE_ISB}} | Operative Steuerung des ISMS |
| {{ROLE_IT_LEAD}} | Technische Umsetzung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:L00}}, {{LINK:R03}}, {{LINK:R13}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R02_Asset-und-Klassifizierungsrichtlinie.md
+259
View File
@@ -0,0 +1,259 @@
# Richtlinie Asset- und Klassifizierungsrichtlinie
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Identifikation, Klassifizierung und geschützten Umgang mit Informationswerten sowie die Zulassung von Hard- und Software. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Identifikation von Informationswerten
<!-- FW:REF-START ORIG:(ISA 1.3.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.9{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.1-M1 -->
- **[MUSS]** Informationswerte und weitere sicherheitsrelevante Assets der Organisation sind identifiziert und erfasst.
<!-- REQ 1.3.1-M2 -->
- **[MUSS]** Die unterstützenden Assets, die die Informationswerte verarbeiten, sind identifiziert und erfasst.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.1-S1 -->
- **[SOLL]** Ein Katalog der relevanten Informationswerte existiert; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.9-1 -->
- **[ISO A.5.9]** Ein Inventar der Informationen und zugehörigen Assets einschließlich Eigentümer ist zu erstellen und zu pflegen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.1 -->
Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt (siehe {{LINK:VA-08}}); Zu-/Abgänge werden über das {{TOOL_TICKET}} ausgelöst.
### 3.2 Klassifizierung von Informationswerten
<!-- FW:REF-START ORIG:(ISA 1.3.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.12, A.5.13{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.2-M1 -->
- **[MUSS]** Ein konsistentes Schema zur Klassifizierung von Informationswerten hinsichtlich des Schutzziels Vertraulichkeit ist vorhanden.
<!-- REQ 1.3.2-M2 -->
- **[MUSS]** Die Bewertung der identifizierten Informationswerte erfolgt nach den definierten Kriterien und wird dem Klassifizierungsschema zugeordnet.
<!-- REQ 1.3.2-M3 -->
- **[MUSS]** Vorgaben zur Handhabung unterstützender Assets (z. B. Kennzeichnung, Nutzung, Transport, Speicherung, Rückgabe, Löschung/Vernichtung) abhängig von der Klassifizierung sind vorhanden und umgesetzt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.2-S1 -->
- **[SOLL]** Die Schutzziele Integrität und Verfügbarkeit werden berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.12-1 -->
- **[ISO A.5.12]** Informationen sind entsprechend ihrem Schutzbedarf (Vertraulichkeit, Integrität, Verfügbarkeit) zu klassifizieren.
<!-- REQ A.5.13-1 -->
- **[ISO A.5.13]** Verfahren zur Kennzeichnung von Informationen gemäß dem Klassifizierungsschema sind zu entwickeln und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.2 -->
Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht (siehe {{LINK:VA-08}}).
### 3.3 Nutzung freigegebener externer IT-Dienste/Hardware
<!-- FW:REF-START ORIG:(ISA 1.3.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.10{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.3-M1 -->
- **[MUSS]** Externe IT-Dienste werden nicht ohne ausdrückliche Bewertung und Umsetzung der Informationssicherheitsanforderungen genutzt; dabei werden die einschlägigen Aspekte berücksichtigt.
<!-- REQ 1.3.3-M2 -->
- **[MUSS]** Die externen IT-Dienste sind mit dem Schutzbedarf der verarbeiteten Informationswerte abgestimmt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S1 -->
- **[SOLL]** Anforderungen an Beschaffung, Inbetriebnahme und Freigabe im Zusammenhang mit der Nutzung externer IT-Dienste sind bestimmt und erfüllt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S2 -->
- **[SOLL]** Ein Verfahren zur Freigabe unter Berücksichtigung des Schutzbedarfs ist etabliert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S3 -->
- **[SOLL]** Externe IT-Dienste und ihre Freigabe sind dokumentiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.3-S4 -->
- **[SOLL]** Es wird regelmäßig überprüft, dass nur freigegebene externe IT-Dienste genutzt werden.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.10-1 -->
- **[ISO A.5.10]** Regeln zur zulässigen Nutzung und zum Umgang mit Informationen und Assets sind festzulegen, zu dokumentieren und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.3 -->
Externe IT-Dienste/-Komponenten werden vor Nutzung bewertet, mit dem Schutzbedarf abgestimmt und über ein definiertes Verfahren freigegeben; die Freigaben werden im Register externe IT-/Cloud-/KI-Dienste ({{LINK:REG-EXT-SERVICES}}) geführt (Lieferant {{LINK:VA-10}}, Asset {{LINK:VA-08}}) und regelmäßig auf ausschließliche Nutzung freigegebener Dienste geprüft.
### 3.4 Freigabe von Software
<!-- FW:REF-START ORIG:(ISA 1.3.4) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.3.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.19{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.3.4-M1 -->
- **[MUSS]** Software wird vor Installation oder Nutzung freigegeben; dabei werden die einschlägigen Aspekte berücksichtigt.
<!-- REQ 1.3.4-M2 -->
- **[MUSS]** Die Softwarefreigabe gilt auch für Spezialsoftware wie Wartungswerkzeuge.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S1 -->
- **[SOLL]** Die zu verwaltenden Softwarearten (Firmware, Betriebssysteme, Anwendungen, Bibliotheken, Gerätetreiber) sind bestimmt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S2 -->
- **[SOLL]** Repositorys der verwalteten Software existieren.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S3 -->
- **[SOLL]** Die Software-Repositorys sind gegen unbefugte Manipulation geschützt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S4 -->
- **[SOLL]** Die Freigabe von Software wird regelmäßig überprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.3.4-S5 -->
- **[SOLL]** Softwareversionen und Patch-Stände sind bekannt.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.3.4-V1 -->
- **[SEHR HOCH]** Zusätzliche Anforderungen an die Softwarenutzung (z. B. Kontroll-/Überwachungsbedarf der Nutzung) sind, sofern vorhanden, bestimmt. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.19-1 -->
- **[ISO A.8.19]** Verfahren und Maßnahmen zur sicheren Verwaltung der Softwareinstallation auf Produktivsystemen sind umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.4 -->
Software (inkl. Spezial-/Wartungssoftware) wird vor Einsatz freigegeben; zugelassene Software wird im Register Software-Whitelist ({{LINK:REG-SW-WHITELIST}}) mit Version/Patch-Stand, Quelle/Lieferant ({{LINK:VA-10}}) und Freigabestatus geführt und ist mit dem Asset-Inventar ({{LINK:VA-08}}) verknüpft; Beschaffung/Freigabe läuft über das {{TOOL_TICKET}}. Verwaltete Softwarearten sind bestimmt, Repositorys gegen Manipulation geschützt und Freigaben werden regelmäßig überprüft.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.3.4-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf sind zusätzliche Kontroll-/Überwachungsanforderungen an die Softwarenutzung bestimmt und umgesetzt.{{/if}}
{{/if}}
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Datenmaskierung und Pseudonymisierung
*Anforderungsbezug:* ISO/IEC 27001 A.8.11
**Anforderung**
<!-- REQ A.8.11-1 -->
- **[ISO A.8.11]** Datenmaskierung ist gemäß den Zugriffs- und Datenschutzanforderungen einzusetzen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MASKIERUNG -->
Wo der volle Informationsgehalt für den Verwendungszweck nicht erforderlich ist, werden Daten maskiert, pseudonymisiert oder anonymisiert. Das gilt insbesondere für Test-, Schulungs- und Entwicklungsumgebungen ({{LINK:R11}}), für Auswertungen sowie für Anzeigen mit eingeschränktem Zugriffsbedarf. Umfang und Verfahren richten sich nach der Klassifizierung und den Datenschutzanforderungen ({{LINK:R14}}); die Zulässigkeit einer Wiederherstellung des Personenbezugs und deren Absicherung sind geregelt.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Asset-Inventar, Zulassung Hard-/Software |
| {{ROLE_ISB}} | Klassifizierungsschema |
| Asset Owner | Pflege einzelner Assets |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-08}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R01}}, {{LINK:R08}}, {{LINK:R11}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R03_Risikomanagement-und-Auditrichtlinie.md
+289
View File
@@ -0,0 +1,289 @@
# Richtlinie Risikomanagement- und Auditrichtlinie
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken sowie interne und unabhängige Überprüfungen. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Risikomanagement
<!-- FW:REF-START ORIG:(ISA 1.4.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.4.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 6.1.1, 6.1.2, 8.2, 8.3{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.4.1-M1 -->
- **[MUSS]** Risikobewertungen werden regelmäßig und anlassbezogen durchgeführt.
<!-- REQ 1.4.1-M2 -->
- **[MUSS]** Informationssicherheitsrisiken werden angemessen bewertet (z. B. Eintrittswahrscheinlichkeit und mögliches Schadensausmaß).
<!-- REQ 1.4.1-M3 -->
- **[MUSS]** Informationssicherheitsrisiken werden dokumentiert.
<!-- REQ 1.4.1-M4 -->
- **[MUSS]** Jedem Informationssicherheitsrisiko ist ein Verantwortlicher (Risk Owner) zugeordnet, der für Bewertung und Behandlung verantwortlich ist.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S1 -->
- **[SOLL]** Ein Verfahren zur Identifikation, Bewertung und Behandlung von Sicherheitsrisiken ist vorhanden.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S2 -->
- **[SOLL]** Kriterien für Bewertung und Behandlung von Sicherheitsrisiken existieren.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S3 -->
- **[SOLL]** Maßnahmen zur Risikobehandlung und ihre Verantwortlichen sind festgelegt und dokumentiert; ein Maßnahmenplan bzw. eine Umsetzungsübersicht wird nachverfolgt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.4.1-S4 -->
- **[SOLL]** Bei Änderungen des Umfelds (z. B. Organisationsstruktur, Standort, Regularien) erfolgt zeitnah eine Neubewertung.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 6.1.1-1 -->
- **[ISO 6.1.1]** Bei der Planung des ISMS sind Risiken und Chancen zu bestimmen, die zu behandeln sind.
<!-- REQ 6.1.2-1 -->
- **[ISO 6.1.2]** Ein Prozess zur Risikobeurteilung mit definierten Kriterien, Wiederholbarkeit und vergleichbaren Ergebnissen ist festzulegen und anzuwenden.
<!-- REQ 8.2-1 -->
- **[ISO 8.2]** Risikobeurteilungen sind in geplanten Abständen und bei wesentlichen Änderungen durchzuführen und zu dokumentieren.
<!-- REQ 8.3-1 -->
- **[ISO 8.3]** Der Risikobehandlungsplan ist umzusetzen; die Ergebnisse sind zu dokumentieren.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.4.1 -->
Das dokumentierte Risikomanagement-Verfahren (siehe {{LINK:VA-09}}) mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.
### 3.2 Prüfung der Einhaltung im IS-Betrieb
<!-- FW:REF-START ORIG:(ISA 1.5.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.5.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.36{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.5.1-M1 -->
- **[MUSS]** Die Einhaltung der Richtlinien wird organisationsweit überprüft.
<!-- REQ 1.5.1-M2 -->
- **[MUSS]** Informationssicherheitsrichtlinien und -verfahren werden regelmäßig überprüft.
<!-- REQ 1.5.1-M3 -->
- **[MUSS]** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.
<!-- REQ 1.5.1-M4 -->
- **[MUSS]** Die Einhaltung von Informationssicherheitsanforderungen (z. B. technische Vorgaben) wird regelmäßig überprüft.
<!-- REQ 1.5.1-M5 -->
- **[MUSS]** Die Ergebnisse der durchgeführten Überprüfungen werden aufgezeichnet und aufbewahrt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.5.1-S1 -->
- **[SOLL]** Ein Plan für Inhalt und Rahmenbedingungen (Zeitplan, Umfang, Controls) der durchzuführenden Überprüfungen liegt vor.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.36-1 -->
- **[ISO A.5.36]** Die Einhaltung der Informationssicherheitspolitik, themenspezifischer Richtlinien, Regeln und Standards ist regelmäßig zu überprüfen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.5.1 -->
Die Einhaltung von Richtlinien, Verfahren und technischen Anforderungen wird organisationsweit nach dem Audit-Programm ({{LINK:REG-AUDIT-PLAN}}) und dem Audit-/Complianceprüfungs-Verfahren ({{LINK:VA-15}}) durch interne Audits und Kontrollen regelmäßig überprüft (Turnus BL-GOV-01); Ergebnisse werden aufgezeichnet und aufbewahrt, Abweichungen als Maßnahmen im {{TOOL_NAME}} nachverfolgt; Verantwortlich: {{ROLE_ISB}}.
### 3.3 Unabhängige Überprüfung des ISMS
<!-- FW:REF-START ORIG:(ISA 1.5.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.5.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 9.2, A.5.35{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.5.2-M1 -->
- **[MUSS]** Informationssicherheitsüberprüfungen werden durch eine unabhängige und kompetente Stelle regelmäßig und nach grundlegenden Änderungen durchgeführt.
<!-- REQ 1.5.2-M2 -->
- **[MUSS]** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.5.2-S1 -->
- **[SOLL]** Die Ergebnisse durchgeführter Überprüfungen werden dokumentiert und der Organisationsleitung berichtet.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 9.2-1 -->
- **[ISO 9.2]** Interne Audits sind in geplanten Abständen durchzuführen, um die Konformität und wirksame Umsetzung des ISMS zu prüfen.
<!-- REQ A.5.35-1 -->
- **[ISO A.5.35]** Der Ansatz der Organisation zur Steuerung der Informationssicherheit ist unabhängig und in geplanten Abständen zu überprüfen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.5.2 -->
Das ISMS wird regelmäßig und nach grundlegenden Änderungen durch eine unabhängige, kompetente Stelle (interne Revision oder externe Auditierung, z. B. TISAX) überprüft; Ergebnisse werden dokumentiert, der {{ROLE_MANAGEMENT}} berichtet und Abweichungen als Maßnahmen verfolgt.
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Erklärung zur Anwendbarkeit (SoA)
*Anforderungsbezug:* ISO/IEC 27001 6.1.3
**Anforderung**
<!-- REQ 6.1.3-1 -->
- **[ISO 6.1.3]** Ein Risikobehandlungsprozess ist festzulegen; erforderliche Controls sind zu bestimmen und mit Annex A abzugleichen (Statement of Applicability).
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-SOA -->
Aus der Risikobehandlung wird bestimmt, welche Maßnahmen erforderlich sind; das Ergebnis wird mit Anhang A abgeglichen, um übersehene Maßnahmen zu erkennen. Die Erklärung zur Anwendbarkeit wird im {{TOOL_NAME}} geführt und enthält je Control: Anwendbarkeit, Begründung der Einbeziehung, Herkunft (Risiko-ID, gesetzliche oder vertragliche Anforderung), Umsetzungsstatus, verantwortliche Rolle, Verweis auf Richtlinie und Verfahren sowie Nachweis; bei Ausschluss wird die Begründung dokumentiert. Der Risikobehandlungsplan und die Akzeptanz der verbleibenden Risiken werden von den jeweiligen Risikoeigentümern genehmigt; die SoA wird von {{ROLE_MANAGEMENT}} freigegeben und bei jeder Risikobeurteilung ({{RISK_REVIEW_CYCLE}}) aktualisiert.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.5 Betriebliche Planung und Steuerung
*Anforderungsbezug:* ISO/IEC 27001 8.1
**Anforderung**
<!-- REQ 8.1-1 -->
- **[ISO 8.1]** Die zur Erfüllung der Anforderungen nötigen Prozesse sind zu planen, umzusetzen und zu steuern; geplante Änderungen sind zu kontrollieren.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-BETRIEB -->
Die zur Erfüllung der Informationssicherheitsanforderungen erforderlichen Prozesse sind in den Verfahrensanweisungen festgelegt und werden im {{TOOL_NAME}} gesteuert; je Prozess sind Auslöser, verantwortliche Rolle, Fristen und Nachweise bestimmt. Geplante Änderungen werden gesteuert und ihre Folgen bewertet; unbeabsichtigte Änderungen werden überprüft und erforderlichenfalls korrigiert. Ausgelagerte Prozesse werden über die Lieferantensteuerung ({{LINK:R13}}) bestimmt und überwacht. Nachweise über die planmäßige Durchführung werden im Nachweisregister ({{LINK:NACHWEISREGISTER}}) geführt.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.6 Überwachung, Messung, Analyse und Bewertung
*Anforderungsbezug:* ISO/IEC 27001 9.1
**Anforderung**
<!-- REQ 9.1-1 -->
- **[ISO 9.1]** Die Informationssicherheitsleistung und die Wirksamkeit des ISMS sind zu überwachen, zu messen, zu analysieren und zu bewerten.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-MESSUNG -->
Für die Bewertung der Informationssicherheitsleistung und der Wirksamkeit des ISMS ist festgelegt, was gemessen wird (Kennzahlenblatt im {{TOOL_NAME}}), mit welcher Methode und Datenquelle, in welchem Takt gemessen wird, wer misst, wann die Ergebnisse ausgewertet werden und wer sie auswertet. Die Kennzahlen decken mindestens Vorfallbearbeitung, Schwachstellen- und Patchbehebung, Rezertifizierung von Berechtigungen, Wiederherstellungstests, Awareness-Teilnahme und offene Maßnahmen ab; je Kennzahl sind Zielwert und verantwortliche Rolle hinterlegt. Ergebnisse und Trends gehen {{MGMT_REVIEW_CYCLE}} in die Managementbewertung ein; eine Abweichung vom Zielwert löst eine Maßnahme aus.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.7 Managementbewertung
*Anforderungsbezug:* ISO/IEC 27001 9.3
**Anforderung**
<!-- REQ 9.3-1 -->
- **[ISO 9.3]** Die oberste Leitung hat das ISMS in geplanten Abständen zu bewerten (Managementbewertung).
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-MGMTREVIEW -->
{{ROLE_MANAGEMENT}} bewertet das ISMS mindestens {{MGMT_REVIEW_CYCLE}} anhand einer festen Tagesordnung (BL-GOV-02). Eingaben sind mindestens: Status der Maßnahmen aus früheren Bewertungen; Änderungen relevanter interner und externer Themen sowie der Anforderungen interessierter Parteien; Rückmeldungen zur Informationssicherheitsleistung (Nichtkonformitäten und Korrekturmaßnahmen, Überwachungs- und Messergebnisse, Auditergebnisse, Erreichung der Informationssicherheitsziele); Rückmeldungen interessierter Parteien; Ergebnisse der Risikobeurteilung und Status des Risikobehandlungsplans; Verbesserungsmöglichkeiten. Ergebnisse sind Entscheidungen zu Verbesserungsmöglichkeiten und zu Änderungsbedarf am ISMS, jeweils mit verantwortlicher Rolle und Termin. Das Protokoll wird im {{TOOL_NAME}} aufbewahrt.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.8 Nichtkonformität, Korrekturmaßnahmen und fortlaufende Verbesserung
*Anforderungsbezug:* ISO/IEC 27001 10.1, 10.2
**Anforderung**
<!-- REQ 10.1-1 -->
- **[ISO 10.1]** Die Eignung, Angemessenheit und Wirksamkeit des ISMS ist fortlaufend zu verbessern.
<!-- REQ 10.2-1 -->
- **[ISO 10.2]** Bei Nichtkonformitäten sind Korrekturen vorzunehmen und Korrekturmaßnahmen zur Beseitigung der Ursachen zu ergreifen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-MS-CAPA -->
Nichtkonformitäten aus Audits, Kontrollen, Vorfällen, Kennzahlenabweichungen und Hinweisen werden im {{TOOL_NAME}} erfasst. Je Fall werden die Sofortkorrektur und der Umgang mit den Folgen festgelegt, die Ursache analysiert und bewertet, ob gleichartige Nichtkonformitäten anderswo bestehen oder auftreten können. Erforderliche Korrekturmaßnahmen werden mit verantwortlicher Rolle und Termin umgesetzt; ihre Wirksamkeit wird nach Ablauf des festgelegten Wirksamkeitsintervalls bewertet und erforderlichenfalls werden Risiken, Maßnahmen und Dokumente angepasst. Art der Nichtkonformität, ergriffene Maßnahmen und Ergebnis der Wirksamkeitsbewertung werden aufbewahrt. Eignung, Angemessenheit und Wirksamkeit des ISMS werden fortlaufend verbessert; der Nachweis erfolgt über Kennzahlen und Managementbewertung.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Risikomanagement, Audits |
| {{ROLE_MANAGEMENT}} | Risikoakzeptanz |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-09}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R01}}, {{LINK:R04}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R04_Incident-Notfall-und-Kontinuitaetsrichtlinie.md
+383
View File
@@ -0,0 +1,383 @@
# Richtlinie Incident-, Notfall- und Kontinuitätsrichtlinie
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Meldung und Behandlung von Sicherheitsereignissen, Krisenmanagement sowie Notfall- und Kontinuitätsplanung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Meldung von Sicherheitsereignissen
<!-- FW:REF-START ORIG:(ISA 1.6.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.24, A.6.8{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.1-M1 -->
- **[MUSS]** Eine Definition für ein meldepflichtiges Sicherheitsereignis oder eine Beobachtung existiert und ist Beschäftigten und relevanten Stakeholdern bekannt.
<!-- REQ 1.6.1-M2 -->
- **[MUSS]** Angemessene, risikoorientierte Mechanismen zur Meldung von Sicherheitsereignissen sind definiert, umgesetzt und allen relevanten Meldenden bekannt.
<!-- REQ 1.6.1-M3 -->
- **[MUSS]** Angemessene Kanäle zur Kommunikation mit Meldenden existieren.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S1 -->
- **[SOLL]** Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S2 -->
- **[SOLL]** Verschiedene Meldekanäle je nach wahrgenommener Schwere (Echtzeit für gravierende Ereignisse/Notfälle sowie asynchrone Mechanismen wie Tickets oder E-Mail) sind verfügbar.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S3 -->
- **[SOLL]** Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S4 -->
- **[SOLL]** Sicherheitsereignisse können auch durch Externe gemeldet werden; die einschlägigen Aspekte werden berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S5 -->
- **[SOLL]** Der Mechanismus und die Information, wie Vorfälle gemeldet werden, sind für alle relevanten Meldenden zugänglich.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.1-S6 -->
- **[SOLL]** Ein Rückmeldeverfahren an die Meldenden ist etabliert.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.1-V1 -->
- **[SEHR HOCH]** Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.24-1 -->
- **[ISO A.5.24]** Das Management von Informationssicherheitsvorfällen ist zu planen und vorzubereiten (Rollen, Prozesse, Verantwortlichkeiten).
<!-- REQ A.6.8-1 -->
- **[ISO A.6.8]** Ein Mechanismus zur zeitnahen Meldung beobachteter oder vermuteter Informationssicherheitsereignisse ist bereitzustellen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.1 -->
Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert (siehe {{LINK:VA-01}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.1-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.{{/if}}
{{/if}}
### 3.2 Behandlung von Sicherheitsereignissen
<!-- FW:REF-START ORIG:(ISA 1.6.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.25, A.5.26, A.5.27, A.5.28{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.2-M1 -->
- **[MUSS]** Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet.
<!-- REQ 1.6.2-M2 -->
- **[MUSS]** Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt.
<!-- REQ 1.6.2-M3 -->
- **[MUSS]** Lessons Learned fließen in die kontinuierliche Verbesserung ein.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S1 -->
- **[SOLL]** Gemeldete Ereignisse werden bei der Bearbeitung kategorisiert (z. B. Personal, physisch, Cyber), qualifiziert (z. B. nicht sicherheitsrelevant, Beobachtung, Verbesserungsvorschlag, Schwachstelle, Vorfall) und priorisiert (z. B. gering, mittel, schwer, kritisch).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S2 -->
- **[SOLL]** Verantwortlichkeiten für die Behandlung von Ereignissen je Kategorie sind definiert und zugewiesen.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.2-S3 -->
- **[SOLL]** Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an zuständige Behörden, sofern erforderlich, existiert. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H1 -->
- **[HOCH]** Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H2 -->
- **[HOCH]** Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H3 -->
- **[HOCH]** Gesetzliche, regulatorische und vertragliche Meldepflichten sowie zugehörige Kontaktinformationen sind bekannt. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H4 -->
- **[HOCH]** Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.2-H5 -->
- **[HOCH]** Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.2-V1 -->
- **[SEHR HOCH]** Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßig getestet; die einschlägigen Aspekte werden berücksichtigt. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.25-1 -->
- **[ISO A.5.25]** Informationssicherheitsereignisse sind zu bewerten und es ist zu entscheiden, ob sie als Informationssicherheitsvorfälle einzustufen sind.
<!-- REQ A.5.26-1 -->
- **[ISO A.5.26]** Auf Informationssicherheitsvorfälle ist gemäß dokumentierten Verfahren zu reagieren.
<!-- REQ A.5.27-1 -->
- **[ISO A.5.27]** Aus Informationssicherheitsvorfällen gewonnene Erkenntnisse sind zur Stärkung der Maßnahmen zu nutzen.
<!-- REQ A.5.28-1 -->
- **[ISO A.5.28]** Verfahren zur Identifizierung, Sammlung, Beschaffung und Aufbewahrung von Beweismaterial zu Vorfällen sind festzulegen und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.2 -->
Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren (siehe {{LINK:VA-01}}) im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.2-elev -->
Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskalationen für nicht prioritätsgerecht bearbeitete Ereignisse geregelt, Meldepflichten und Kontakte bekannt, eine Kommunikationsstrategie sowie ein Verfahren für Lieferantenvorfälle etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.{{/if}}
{{/if}}
### 3.3 Krisenmanagement
<!-- FW:REF-START ORIG:(ISA 1.6.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 1.6.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.29{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 1.6.3-M1 -->
- **[MUSS]** Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert und die erforderlichen Ressourcen sind verfügbar.
<!-- REQ 1.6.3-M2 -->
- **[MUSS]** Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert und zugewiesen.
<!-- REQ 1.6.3-M3 -->
- **[MUSS]** Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S1 -->
- **[SOLL]** Methoden zur Erkennung von Krisensituationen sind etabliert; allgemeine Anzeichen und spezifische vorhersehbare Krisen sind identifiziert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S2 -->
- **[SOLL]** Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S3 -->
- **[SOLL]** Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und relevantem Personal bekannt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S4 -->
- **[SOLL]** Ein Krisenstab ist definiert und genehmigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S5 -->
- **[SOLL]** Krisenrichtlinien und -verfahren sind definiert und genehmigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 1.6.3-S6 -->
- **[SOLL]** Die Krisenplanung wird regelmäßig überprüft und aktualisiert.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H1 -->
- **[HOCH]** Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H2 -->
- **[HOCH]** Notwendige Ressourcen und Informationen zur Krisenbewältigung (z. B. Kommunikationsinfrastruktur, Verfügbarkeit von Kontakt- und Risikoinformationen) sind identifiziert; angemessene Maßnahmen zur Sicherstellung der Verfügbarkeit bzw. Ausfallplanung sind vorhanden. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H3 -->
- **[HOCH]** Eine Kommunikationsstrategie für Krisensituationen existiert. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H4 -->
- **[HOCH]** Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewertet. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 1.6.3-H5 -->
- **[HOCH]** Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tabletop-Übungen mit Schlüsselpersonal). (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 1.6.3-V1 -->
- **[SEHR HOCH]** Krisenübungen und Simulationen unter Einbindung aller relevanten Personen, einschließlich Entscheidungsträger, werden regelmäßig durchgeführt. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.29-1 -->
- **[ISO A.5.29]** Die Aufrechterhaltung der Informationssicherheit während Störungen ist zu planen und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.3 -->
Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert (Auslösung/Wiederanlauf siehe {{LINK:VA-02}}); erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.3-elev -->
Bei hohem Schutzbedarf sind relevante Krisenszenarien identifiziert, notwendige Ressourcen/Informationen und eine Kommunikationsstrategie sichergestellt, die Planung wird regelmäßig bewertet und stichprobenartig getestet (Tabletop). {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.{{/if}}
{{/if}}
### 3.4 Kontinuitätsplanung für IT-Dienste
<!-- FW:REF-START ORIG:(ISA 5.2.8) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.8{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.30, A.8.14{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.8-M1 -->
- **[MUSS]** Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt.
<!-- REQ 5.2.8-M2 -->
- **[MUSS]** Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung dieser IT-Dienste sind relevanten Stakeholdern bekannt und erfüllt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S1 -->
- **[SOLL]** Kritische IT-Systeme sind identifiziert; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S2 -->
- **[SOLL]** Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.8-S3 -->
- **[SOLL]** Die Kontinuitätsplanung umfasst mindestens (D)DoS-Angriffe, erfolgreiche Ransomware-Angriffe und andere Sabotage, Systemausfallszenarien sowie Naturkatastrophen, die kritische IT-Systeme betreffen.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H1 -->
- **[HOCH]** Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (Recovery Time Objective) für die Wiederaufnahme des Betriebs. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H2 -->
- **[HOCH]** Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H3 -->
- **[HOCH]** Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit Geschäftspartnern. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H4 -->
- **[HOCH]** Die Kontinuitätsplanung wird regelmäßig getestet, inkl. vollständiger Wiederherstellung in einen bekannten Zustand und Einhaltung definierter Zielzeiten. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H5 -->
- **[HOCH]** Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste und Informationen ist definiert und umgesetzt. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H6 -->
- **[HOCH]** Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugte Veränderung/Löschung durch Schadsoftware geschützt. (I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.8-H7 -->
- **[HOCH]** Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugten Zugriff durch Schadsoftware oder Betreiber geschützt. (C, I)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V1 -->
- **[SEHR HOCH]** Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister abgestimmt. (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V2 -->
- **[SEHR HOCH]** Die Fortführung wesentlicher Kern- und Geschäftsfunktionen mit minimalem oder keinem Verlust an Betriebskontinuität ist möglich; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.8-V3 -->
- **[SEHR HOCH]** Die Kontinuitätsplanung wird regelmäßig getestet. Testszenarien, Ergebnisse und Lessons Learned werden aufgezeichnet. (I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.30-1 -->
- **[ISO A.5.30]** Die IKT-Bereitschaft ist auf Basis der Business-Continuity-Ziele und -Anforderungen zu planen, umzusetzen und zu testen.
<!-- REQ A.8.14-1 -->
- **[ISO A.8.14]** Informationsverarbeitende Einrichtungen sind mit ausreichender Redundanz auszulegen, um die Verfügbarkeitsanforderungen zu erfüllen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.8 -->
Kritische IT-Dienste sind mit Geschäftsauswirkung im Register kritischer IT-Dienste ({{LINK:REG-CRIT-SERVICES}}) (inkl. BIA-Einstufung, RTO/RPO, Wiederanlaufreihenfolge) erfasst; Anforderungen und Verantwortlichkeiten für Kontinuität/Wiederherstellung sind bekannt und erfüllt. Eine Kontinuitätsplanung (inkl. (D)DoS, Ransomware, Ausfall, Naturkatastrophen) besteht, wird regelmäßig überprüft und über das IT-Notfallverfahren umgesetzt (siehe {{LINK:VA-02}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.8-elev -->
Bei hohem Schutzbedarf sind RTO/RPO, SLAs mit Dienstleistern, Partnerkommunikation, regelmäßige Volltests sowie eine geschützte Backup-/Recovery-Strategie (immutable/isoliert) etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf ist die Planung mit externen Dienstleistern abgestimmt, die Fortführung wesentlicher Funktionen sichergestellt und Tests inkl. Lessons Learned werden aufgezeichnet.{{/if}}
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Vorfallskoordination |
| {{ROLE_IT_LEAD}} | Notfall-/Wiederanlaufplanung |
| {{ROLE_MANAGEMENT}} | Krisenstab |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-01}}, {{LINK:VA-02}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R03}}, {{LINK:R10}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R05_Personalsicherheit-und-Awareness.md
+221
View File
@@ -0,0 +1,221 @@
# Richtlinie Personalsicherheit und Awareness
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_HR_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Eignung, vertragliche Verpflichtung sowie Schulung und Sensibilisierung des Personals. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Qualifikation für sensible Tätigkeiten
<!-- FW:REF-START ORIG:(ISA 2.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 7.2, A.6.1{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.1-M1 -->
- **[MUSS]** Sensible Arbeitsbereiche und Tätigkeiten sind bestimmt.
<!-- REQ 2.1.1-M2 -->
- **[MUSS]** Die Anforderungen an Beschäftigte hinsichtlich ihrer Stellenprofile sind bestimmt und erfüllt.
<!-- REQ 2.1.1-M3 -->
- **[MUSS]** Die Identität potenzieller Beschäftigter wird verifiziert (z. B. Prüfung von Ausweisdokumenten).
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.1-S1 -->
- **[SOLL]** Die persönliche Eignung potenzieller Beschäftigter wird mit einfachen Methoden überprüft (z. B. Vorstellungsgespräch).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.1-S2 -->
- **[SOLL]** Eine erweiterte Eignungsprüfung abhängig vom Arbeitsbereich und der Tätigkeit wird durchgeführt (z. B. Assessment-Center, Prüfung von Referenzen, Zeugnissen und Führungszeugnissen).
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 7.2-1 -->
- **[ISO 7.2]** Erforderliche Kompetenzen sind zu bestimmen und sicherzustellen; entsprechende Nachweise sind zu führen.
<!-- REQ A.6.1-1 -->
- **[ISO A.6.1]** Hintergrundüberprüfungen von Bewerbern sind angemessen zu den Geschäftsanforderungen und gesetzeskonform durchzuführen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 2.1.1 -->
Sensible Arbeitsbereiche und Tätigkeiten sind im Register sensibler Tätigkeiten ({{LINK:REG-SENS-ROLES}}) bestimmt und mit der geforderten Prüftiefe hinterlegt; Anforderungen an Positionen sind in Stellenbeschreibungen dokumentiert und werden erfüllt. Identitätsverifizierung sowie die persönliche und – bei sensiblen Rollen – erweiterte Eignungsprüfung (Gespräch, Referenzen, Führungszeugnis im rechtlich zulässigen Rahmen) erfolgen nach dem Eignungs- und Verifizierungsverfahren ({{LINK:VA-14}}); Verantwortlich: {{ROLE_HR_LEAD}}; Nachweis in der Personalakte.
### 3.2 Vertragliche Verpflichtung des Personals
<!-- FW:REF-START ORIG:(ISA 2.1.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.6.2, A.6.5, A.6.6{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.2-M1 -->
- **[MUSS]** Eine Vertraulichkeitsverpflichtung ist in Kraft.
<!-- REQ 2.1.2-M2 -->
- **[MUSS]** Eine Verpflichtung zur Einhaltung der Informationssicherheitsrichtlinien ist in Kraft.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S1 -->
- **[SOLL]** Eine über den Arbeitsvertrag hinausgehende Vertraulichkeitsverpflichtung ist in Kraft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S2 -->
- **[SOLL]** Informationssicherheitsaspekte werden in den Arbeitsverträgen der Beschäftigten berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.2-S3 -->
- **[SOLL]** Ein Verfahren zum Umgang mit Verstößen gegen diese Verpflichtungen ist beschrieben.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.6.2-1 -->
- **[ISO A.6.2]** Die arbeitsvertraglichen Vereinbarungen legen die Verantwortlichkeiten für die Informationssicherheit fest.
<!-- REQ A.6.5-1 -->
- **[ISO A.6.5]** Fortbestehende Informationssicherheitsverantwortlichkeiten nach Beendigung oder Wechsel des Beschäftigungsverhältnisses sind zu definieren und durchzusetzen.
<!-- REQ A.6.6-1 -->
- **[ISO A.6.6]** Vertraulichkeits- bzw. Geheimhaltungsvereinbarungen sind zu identifizieren, zu dokumentieren und regelmäßig zu überprüfen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 2.1.2 -->
Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur Einhaltung der Informationssicherheitsrichtlinien verpflichtet ({{ROLE_HR_LEAD}}); Informationssicherheitsaspekte sind Bestandteil der Arbeitsverträge, die Vertraulichkeit gilt nachvertraglich fort. Ein dokumentiertes Verfahren zum Umgang mit Verstößen (siehe {{LINK:VA-14}}) ist etabliert; der Nachweis wird in der Personalakte geführt.
### 3.3 Sensibilisierung und Schulung
<!-- FW:REF-START ORIG:(ISA 2.1.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 7.3, A.6.3{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.3-M1 -->
- **[MUSS]** Beschäftigte werden geschult und sensibilisiert.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S1 -->
- **[SOLL]** Ein Konzept für Sensibilisierung und Schulung der Beschäftigten ist erstellt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S2 -->
- **[SOLL]** Zielgruppen für Schulungs- und Sensibilisierungsmaßnahmen (z. B. Führungskräfte, Administratoren, Beschäftigte mit Zugang zu Kundennetzen, Fertigungspersonal) sind identifiziert und im Konzept berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S3 -->
- **[SOLL]** Das Konzept ist durch die verantwortliche Leitung genehmigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S4 -->
- **[SOLL]** Schulungs- und Sensibilisierungsmaßnahmen werden regelmäßig und anlassbezogen durchgeführt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S5 -->
- **[SOLL]** Die Teilnahme an Schulungs- und Sensibilisierungsmaßnahmen wird dokumentiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.3-S6 -->
- **[SOLL]** Ansprechpartner für Informationssicherheit sind den Beschäftigten bekannt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ 7.3-1 -->
- **[ISO 7.3]** Personen unter Aufsicht der Organisation müssen sich der Politik, ihres Beitrags und der Folgen von Verstößen bewusst sein.
<!-- REQ A.6.3-1 -->
- **[ISO A.6.3]** Beschäftigte erhalten angemessene Awareness, Aus- und Weiterbildung sowie regelmäßige Aktualisierungen der relevanten Richtlinien.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 2.1.3 -->
Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult (Ablauf siehe {{LINK:VA-12}}). Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.4 Vorgehen bei Verstößen
*Anforderungsbezug:* ISO/IEC 27001 A.6.4
**Anforderung**
<!-- REQ A.6.4-1 -->
- **[ISO A.6.4]** Ein Disziplinarverfahren für Verstöße gegen die Informationssicherheit ist festzulegen und zu kommunizieren.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-DISZIPLIN -->
Für Verstöße gegen die Informationssicherheitsvorgaben besteht ein abgestuftes, dokumentiertes Vorgehen, das im Voraus kommuniziert ist. Es berücksichtigt Art und Schwere des Verstoßes, Vorsatz oder Fahrlässigkeit, Wiederholung sowie den Schulungsstand der betroffenen Person. Das Verfahren wird von {{ROLE_HR_LEAD}} in Abstimmung mit {{ROLE_ISB}} geführt; arbeitsrechtliche Vorgaben und Mitbestimmungsrechte werden gewahrt. Die Anwendung wird vertraulich dokumentiert.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_HR_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_HR_LEAD}} | Verpflichtung, Eignung |
| {{ROLE_ISB}} | Awareness/Schulung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_HR_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-12}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R01}}, {{LINK:R06}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R06_Mobiles-Arbeiten-und-mobile-Geraete.md
+151
View File
@@ -0,0 +1,151 @@
# Richtlinie Mobiles Arbeiten und mobile Geräte
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt mobiles Arbeiten sowie den Umgang mit mobilen IT-Geräten und Datenträgern. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
{{#if FLAG_MOBILE_WORK}}
### 3.1 Mobiles Arbeiten
<!-- FW:REF-START ORIG:(ISA 2.1.4) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 2.1.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.6.7{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 2.1.4-M1 -->
- **[MUSS]** Die Anforderungen an mobiles Arbeiten sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.4-S1 -->
- **[SOLL]** Die einschlägigen Aspekte des mobilen Arbeitens werden berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 2.1.4-S2 -->
- **[SOLL]** Sensibilisierung der Beschäftigten.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 2.1.4-H1 -->
- **[HOCH]** Schutzmaßnahmen gegen Abhören und Einsehen sind umgesetzt. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.6.7-1 -->
- **[ISO A.6.7]** Sicherheitsmaßnahmen für das Arbeiten außerhalb der Räumlichkeiten der Organisation sind umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 2.1.4 -->
Mobiles Arbeiten ist in dieser Richtlinie und der zugehörigen Regelung mobiles Arbeiten (hinterlegt im {{TOOL_NAME}}) festgelegt und die Anforderungen sind erfüllt; der Zugriff erfolgt ausschließlich über {{TECH_VPN}} mit MFA (BL-IAM-02) und freigegebene, verschlüsselte Geräte (BL-CRY-03). Die Beschäftigten sind sensibilisiert (BL-HR-01).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 2.1.4-elev -->
Bei hohem Schutzbedarf sind Schutzmaßnahmen gegen Abhören und Einsehen umgesetzt (z. B. Sichtschutz, ruhige Umgebung, Clean-Screen).
{{/if}}
{{/if}}
{{#if FLAG_MOBILE_DEVICES}}
### 3.2 Mobile IT-Geräte und Datenträger
<!-- FW:REF-START ORIG:(ISA 3.1.4) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 3.1.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.7.9, A.7.10, A.8.1{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 3.1.4-M1 -->
- **[MUSS]** Die Anforderungen an mobile IT-Geräte und mobile Datenträger sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.4-S1 -->
- **[SOLL]** Registrierung der IT-Geräte.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 3.1.4-H1 -->
- **[HOCH]** Generelle Verschlüsselung mobiler Datenträger bzw. der darauf gespeicherten Informationswerte. Wo technisch nicht machbar, werden Informationen durch gleichwertige Maßnahmen geschützt. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.7.9-1 -->
- **[ISO A.7.9]** Assets, die außerhalb der Räumlichkeiten genutzt werden, sind zu schützen.
<!-- REQ A.7.10-1 -->
- **[ISO A.7.10]** Speichermedien sind über ihren gesamten Lebenszyklus (Erwerb, Nutzung, Transport, Entsorgung) entsprechend dem Klassifizierungsschema zu schützen.
<!-- REQ A.8.1-1 -->
- **[ISO A.8.1]** Informationen, die auf Endgeräten der Benutzer gespeichert, verarbeitet oder darüber zugänglich sind, sind zu schützen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 3.1.4 -->
Die Anforderungen an mobile Geräte und Datenträger sind bestimmt und erfüllt: Geräte sind über {{TECH_MDM}} registriert und zentral verwaltet, nur freigegebene Geräte werden genutzt; Verlustmeldung erfolgt über den Meldeweg (R04) und das {{TOOL_TICKET}}, Sperre/Löschung bei Verlust über {{TECH_MDM}} (BL-EP-02).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 3.1.4-elev -->
Bei hohem Schutzbedarf sind mobile Datenträger bzw. die darauf gespeicherten Informationen generell verschlüsselt (BL-CRY-03); wo nicht machbar, greifen gleichwertige Schutzmaßnahmen.
{{/if}}
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Sicherheitsanforderungen |
| {{ROLE_IT_LEAD}} | Technische Umsetzung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R05}}, {{LINK:R07}}, {{LINK:R08}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R07_Physische-Sicherheit.md
+173
View File
@@ -0,0 +1,173 @@
# Richtlinie Physische Sicherheit
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt physischen Schutz durch Sicherheitszonen, Zutrittsschutz und den Umgang mit unterstützenden Betriebsmitteln. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Sicherheitszonen und Zutritt
<!-- FW:REF-START ORIG:(ISA 3.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 3.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.7.1, A.7.2, A.7.3, A.7.4, A.7.6{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 3.1.1-M1 -->
- **[MUSS]** Ein Sicherheitszonenkonzept einschließlich zugehöriger Schutzmaßnahmen auf Basis der Anforderungen an die Handhabung von Informationswerten ist vorhanden.
<!-- REQ 3.1.1-M2 -->
- **[MUSS]** Die definierten Schutzmaßnahmen sind umgesetzt.
<!-- REQ 3.1.1-M3 -->
- **[MUSS]** Der Verhaltenskodex für Sicherheitszonen ist allen beteiligten Personen bekannt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S1 -->
- **[SOLL]** Verfahren für die Vergabe und den Entzug von Zutrittsrechten sind etabliert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S2 -->
- **[SOLL]** Richtlinien für das Besuchermanagement (einschließlich Registrierung und Begleitung von Besuchern) sind definiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S3 -->
- **[SOLL]** Richtlinien für das Mitführen und Nutzen mobiler IT-Geräte und Datenträger (z. B. Registrierung, Kennzeichnungspflichten) sind definiert und umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S4 -->
- **[SOLL]** Netzwerk-/Infrastrukturkomponenten (eigene oder Kundennetze) sind gegen unbefugten Zugriff geschützt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 3.1.1-S5 -->
- **[SOLL]** Externe Liegenschaften zur Speicherung/Verarbeitung von Informationswerten sind im Zonenkonzept berücksichtigt (z. B. Lagerräume, Werkstätten, Teststrecken, Rechenzentren).
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 3.1.1-H1 -->
- **[HOCH]** Schutzmaßnahmen gegen einfaches Abhören und Einsehen sind umgesetzt. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.7.1-1 -->
- **[ISO A.7.1]** Sicherheitsperimeter sind zu definieren und zum Schutz von Bereichen mit Informationen und Assets zu nutzen.
<!-- REQ A.7.2-1 -->
- **[ISO A.7.2]** Sichere Zutrittskontrollen und Zutrittspunkte sind einzurichten, um den Zugang auf Berechtigte zu beschränken.
<!-- REQ A.7.3-1 -->
- **[ISO A.7.3]** Physische Sicherheit für Büros, Räume und Einrichtungen ist zu gestalten und umzusetzen.
<!-- REQ A.7.4-1 -->
- **[ISO A.7.4]** Räumlichkeiten sind kontinuierlich auf unbefugten physischen Zugang zu überwachen.
<!-- REQ A.7.6-1 -->
- **[ISO A.7.6]** Für das Arbeiten in Sicherheitsbereichen sind Maßnahmen festzulegen und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 3.1.1 -->
Ein Sicherheitszonenkonzept (BL-PHY-01) mit umgesetzten Schutzmaßnahmen und bekanntem Verhaltenskodex ist vorhanden; Zutrittsrechte werden über das {{TOOL_TICKET}} bedarfsorientiert vergeben, dokumentiert und bei Wegfall entzogen (BL-PHY-02, Ablauf siehe {{LINK:VA-17}}). Besuchermanagement, Regeln für mobile Geräte, Schutz von Netz-/Infrastrukturkomponenten und externe Liegenschaften sind berücksichtigt.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 3.1.1-elev -->
Bei hohem Schutzbedarf sind zusätzliche Schutzmaßnahmen gegen einfaches Abhören und Einsehen umgesetzt.
{{/if}}
<!-- Scope-Hinweis (E2): ISA 3.1.2 ist in VDA-ISA 2027 deprecated; ISA 3.1.3 existiert nicht.
Daher kein Abschnitt/REQ/IMPL für 3.1.2/3.1.3 in R07 und mapping.json. -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.2 Umgebungsschutz, Versorgung, Verkabelung und Wartung
*Anforderungsbezug:* ISO/IEC 27001 A.7.5, A.7.8, A.7.11, A.7.12, A.7.13
**Anforderung**
<!-- REQ A.7.5-1 -->
- **[ISO A.7.5]** Schutz gegen physische und umweltbedingte Bedrohungen ist zu gestalten und umzusetzen.
<!-- REQ A.7.8-1 -->
- **[ISO A.7.8]** Betriebsmittel sind sicher zu platzieren und zu schützen.
<!-- REQ A.7.11-1 -->
- **[ISO A.7.11]** Einrichtungen sind vor Ausfällen und Störungen der Versorgung (z. B. Strom, Klima) zu schützen.
<!-- REQ A.7.12-1 -->
- **[ISO A.7.12]** Verkabelung für Strom und Daten ist vor Abhören, Störung und Beschädigung zu schützen.
<!-- REQ A.7.13-1 -->
- **[ISO A.7.13]** Betriebsmittel sind ordnungsgemäß zu warten, um Verfügbarkeit und Integrität sicherzustellen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-PHY-UMWELT -->
Standorte und technische Einrichtungen sind gegen physische und umweltbedingte Bedrohungen geschützt (BL-PHY-03): Brandfrüherkennung, Schutz gegen Wasser und Feuchtigkeit, Temperatur- und Feuchteüberwachung in Technikräumen sowie Berücksichtigung standortspezifischer Gefahren. Betriebsmittel sind so platziert, dass Einsicht, unbefugter Zugriff und Umgebungsrisiken minimiert werden. Strom- und Klimaversorgung sind für kritische Systeme unterbrechungsfrei ausgelegt und werden regelmäßig geprüft. Strom- und Datenverkabelung ist gegen Beschädigung und unbefugten Zugriff geschützt und dokumentiert. Betriebsmittel werden nach Herstellervorgabe gewartet; Wartungen erfolgen nur durch berechtigtes Personal, werden geplant und protokolliert und bei externer Durchführung begleitet.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.3 Aufgeräumter Arbeitsplatz und Bildschirmsperre
*Anforderungsbezug:* ISO/IEC 27001 A.7.7
**Anforderung**
<!-- REQ A.7.7-1 -->
- **[ISO A.7.7]** Regeln für einen aufgeräumten Arbeitsplatz und gesperrte Bildschirme sind festzulegen und umzusetzen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-PHY-CLEARDESK -->
Es gelten verbindliche Regeln für einen aufgeräumten Arbeitsplatz und gesperrte Bildschirme (BL-PHY-04): Schutzbedürftige Unterlagen und Datenträger werden bei Abwesenheit verschlossen aufbewahrt; Bildschirme werden beim Verlassen des Arbeitsplatzes gesperrt und sperren automatisch nach {{SESSION_TIMEOUT}}. Ausdrucke werden unmittelbar entnommen, nicht mehr benötigte Unterlagen schutzbedarfsgerecht vernichtet (BL-DEL-01). Die Regeln gelten auch im Homeoffice und an mobilen Arbeitsplätzen ({{LINK:R06}}); die Einhaltung wird stichprobenartig geprüft.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Zonen, Zutritt, Betriebsmittel |
| {{ROLE_ISB}} | Vorgaben |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R02}}, {{LINK:R06}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md
+314
View File
@@ -0,0 +1,314 @@
# Richtlinie Identitäts- und Zugriffsmanagement
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Identifikationsmittel, sichere Anmeldung, Kontenverwaltung sowie Vergabe und Kontrolle von Zugriffsrechten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Umgang mit Identifikationsmitteln
<!-- FW:REF-START ORIG:(ISA 4.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.16{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.1-M1 -->
- **[MUSS]** Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.1-S1 -->
- **[SOLL]** Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.1.1-H1 -->
- **[HOCH]** Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall ist vorbereitet und soweit möglich umgesetzt. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.16-1 -->
- **[ISO A.5.16]** Der vollständige Lebenszyklus von Identitäten ist zu verwalten.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.1.1 -->
Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über das zentrale Verzeichnis ({{TOOL_IAM}}) vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07, siehe {{LINK:VA-03}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.1.1-elev -->
Bei hohem Schutzbedarf besteht eine umgesetzte Strategie zur Sperrung/Ungültigmachung von Identifikationsmitteln im Verlustfall.
{{/if}}
### 3.2 Sichere Anmeldung
<!-- FW:REF-START ORIG:(ISA 4.1.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.2-M1 -->
- **[MUSS]** Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewählt; mögliche Angriffsszenarien (z. B. direkte Erreichbarkeit über das Internet) wurden berücksichtigt.
<!-- REQ 4.1.2-M2 -->
- **[MUSS]** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S1 -->
- **[SOLL]** Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S2 -->
- **[SOLL]** Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.2-S3 -->
- **[SOLL]** Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. Privileged Access Management, Zwei-Faktor-Authentifizierung).
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.1.2-H1 -->
- **[HOCH]** Abhängig von der Risikobewertung sind Authentifizierung und Zugangskontrolle durch ergänzende Maßnahmen verstärkt (z. B. kontinuierliche Zugriffsüberwachung, starke Authentifizierung, automatische Abmeldung, Sperre bei Inaktivität, Brute-Force-Prävention). (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.1.2-V1 -->
- **[SEHR HOCH]** Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Authentifizierung (z. B. Zwei-Faktor) nach dem Stand der Technik authentifiziert. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.5-1 -->
- **[ISO A.8.5]** Sichere Authentisierungstechnologien und -verfahren sind auf Basis der Zugriffsbeschränkungen und der Zugriffssteuerungsrichtlinie einzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.1.2 -->
Die Authentifizierungsverfahren sind risikobasiert ausgewählt und entsprechen dem Stand der Technik; Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden über das zentrale Verzeichnis ({{TOOL_IAM}}) erzwungen. Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA (BL-IAM-02) über {{TECH_MFA}} durchgesetzt; privilegierte Konten nutzen höherwertige Verfahren (PAM).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.1.2-elev -->
Bei hohem Schutzbedarf sind Authentifizierung/Zugangskontrolle durch ergänzende Maßnahmen verstärkt (Zugriffsüberwachung, Auto-Logout BL-IAM-03, Sperre BL-IAM-04, Brute-Force-Schutz). {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf erfolgt der Zugriff nur nach starker Authentifizierung (Zwei-Faktor).{{/if}}
{{/if}}
### 3.3 Benutzerkonten und Anmeldeinformationen
<!-- FW:REF-START ORIG:(ISA 4.1.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.17{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 4.1.3-M1 -->
- **[MUSS]** Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt.
<!-- REQ 4.1.3-M2 -->
- **[MUSS]** Eindeutige und personalisierte Benutzerkonten werden verwendet.
<!-- REQ 4.1.3-M3 -->
- **[MUSS]** Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist).
<!-- REQ 4.1.3-M4 -->
- **[MUSS]** Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende).
<!-- REQ 4.1.3-M5 -->
- **[MUSS]** Benutzerkonten werden regelmäßig überprüft.
<!-- REQ 4.1.3-M6 -->
- **[MUSS]** Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt.
<!-- REQ 4.1.3-M7 -->
- **[MUSS]** Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S1 -->
- **[SOLL]** Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S2 -->
- **[SOLL]** Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S3 -->
- **[SOLL]** Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S4 -->
- **[SOLL]** Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S5 -->
- **[SOLL]** Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S6 -->
- **[SOLL]** Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S7 -->
- **[SOLL]** Die Verwendung von Standardpasswörtern wird technisch verhindert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S8 -->
- **[SOLL]** Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S9 -->
- **[SOLL]** Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.1.3-S10 -->
- **[SOLL]** Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.17-1 -->
- **[ISO A.5.17]** Die Zuteilung und Verwaltung von Authentisierungsinformationen ist durch einen geeigneten Verwaltungsprozess zu steuern.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.1.3 -->
Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) (siehe {{LINK:VA-03}}) eindeutig personalisiert im zentralen Verzeichnis ({{TOOL_IAM}}) verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.
### 3.4 Zugriffsrechte
<!-- FW:REF-START ORIG:(ISA 4.2.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.15, A.5.18, A.8.2, A.8.3, A.8.18{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 4.2.1-M1 -->
- **[MUSS]** Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
<!-- REQ 4.2.1-M2 -->
- **[MUSS]** Die für normale und privilegierte Benutzerkonten sowie technische Konten vergebenen Zugriffsrechte werden regelmäßig überprüft, auch in IT-Systemen von Kunden.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S1 -->
- **[SOLL]** Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S2 -->
- **[SOLL]** Autorisierungsrollen werden verwendet.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S3 -->
- **[SOLL]** Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S4 -->
- **[SOLL]** Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 4.2.1-S5 -->
- **[SOLL]** Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 4.2.1-H1 -->
- **[HOCH]** Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.2.1-V1 -->
- **[SEHR HOCH]** Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unbefugten Zugriff (auch privilegierter Nutzer) zu verhindern. Wo Verschlüsselung nicht machbar ist, greifen gleichwertige Maßnahmen. (C)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 4.2.1-V2 -->
- **[SEHR HOCH]** Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.15-1 -->
- **[ISO A.5.15]** Regeln zur Steuerung des physischen und logischen Zugriffs auf Informationen und Assets sind auf Basis der Geschäfts- und Informationssicherheitsanforderungen festzulegen und umzusetzen.
<!-- REQ A.5.18-1 -->
- **[ISO A.5.18]** Zugriffsrechte sind gemäß der Zugriffssteuerungsrichtlinie zuzuteilen, zu überprüfen, zu ändern und zu entziehen.
<!-- REQ A.8.2-1 -->
- **[ISO A.8.2]** Die Zuteilung und Nutzung privilegierter Zugriffsrechte ist einzuschränken und eng zu steuern.
<!-- REQ A.8.3-1 -->
- **[ISO A.8.3]** Der Zugriff auf Informationen und Anwendungsfunktionen ist gemäß der Zugriffssteuerungsrichtlinie einzuschränken.
<!-- REQ A.8.18-1 -->
- **[ISO A.8.18]** Die Nutzung von Hilfsprogrammen, die System- und Anwendungskontrollen umgehen können, ist einzuschränken und streng zu steuern.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.2.1 -->
Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über das zentrale Verzeichnis ({{TOOL_IAM}}) vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}} (siehe {{LINK:VA-03}}). Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.2.1-elev -->
Bei hohem Schutzbedarf werden Zugriffsrechte durch den verantwortlichen internen Information Officer genehmigt. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Informationen inhaltsverschlüsselt gespeichert (Schutz auch vor privilegierten Nutzern) und Zugriffsrechte in kürzeren Abständen (z. B. quartalsweise) überprüft.{{/if}}
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Technische Umsetzung IAM |
| Fachbereiche | Freigabe von Berechtigungen |
| {{ROLE_ISB}} | Überwachung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-03}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R02}}, {{LINK:R05}}, {{LINK:R10}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R09_Kryptografie-und-Uebertragungsrichtlinie.md
+156
View File
@@ -0,0 +1,156 @@
# Richtlinie Kryptografie- und Übertragungsrichtlinie
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt kryptografische Verfahren, Schlüsselverwaltung und Schutz bei der Informationsübertragung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Einsatz kryptografischer Verfahren
<!-- FW:REF-START ORIG:(ISA 5.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.24{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.1.1-M1 -->
- **[MUSS]** Alle eingesetzten kryptografischen Verfahren (z. B. Verschlüsselung, Signatur, Hash-Algorithmen, Protokolle) bieten die im jeweiligen Anwendungsfeld erforderliche Sicherheit nach anerkanntem Industriestandard, soweit rechtlich möglich.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.1-S1 -->
- **[SOLL]** Ein Konzept für den Einsatz von Kryptografie ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.1.1-H1 -->
- **[HOCH]** Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) sind bestimmt und erfüllt. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.24-1 -->
- **[ISO A.8.24]** Regeln für die wirksame Nutzung von Kryptographie einschließlich Schlüsselverwaltung sind festzulegen und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.1.1 -->
Zulässige Verfahren und Schlüssellängen nach BL-CRY-02 ({{CRYPTO_ALGO}}) entsprechen dem anerkannten Industriestandard und sind vorgegeben; veraltete Verfahren sind untersagt. Ein Kryptokonzept ist dokumentiert (siehe {{LINK:VA-07}}), Schlüssel werden über ihren Lebenszyklus sicher verwaltet (BL-CRY-05).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.1.1-elev -->
Bei hohem Schutzbedarf sind Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) bestimmt und erfüllt.
{{/if}}
### 3.2 Schutz bei der Informationsübertragung
<!-- FW:REF-START ORIG:(ISA 5.1.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.14{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.1.2-M1 -->
- **[MUSS]** Die zur Informationsübertragung genutzten Netzdienste sind identifiziert und dokumentiert.
<!-- REQ 5.1.2-M2 -->
- **[MUSS]** Richtlinien und Verfahren entsprechend den Klassifizierungsanforderungen für die Nutzung von Netzdiensten sind definiert und umgesetzt.
<!-- REQ 5.1.2-M3 -->
- **[MUSS]** Maßnahmen zum Schutz übertragener Inhalte gegen unbefugten Zugriff sind umgesetzt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S1 -->
- **[SOLL]** Maßnahmen zur Sicherstellung korrekter Adressierung und korrekter Informationsübertragung sind umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S2 -->
- **[SOLL]** Elektronischer Datenaustausch erfolgt mittels Inhalts- oder Transportverschlüsselung entsprechend der jeweiligen Klassifizierung.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.1.2-S3 -->
- **[SOLL]** Fernzugriffsverbindungen zum Netzwerk der Organisation verfügen über angemessene Sicherheitsmerkmale; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.1.2-H1 -->
- **[HOCH]** Informationen werden verschlüsselt übertragen (mindestens Transportverschlüsselung) oder durch gleichwertig wirksame Maßnahmen geschützt. (C)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.1.2-V1 -->
- **[SEHR HOCH]** Informationen werden inhaltsverschlüsselt übertragen. (C)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.14-1 -->
- **[ISO A.5.14]** Regeln, Verfahren und Vereinbarungen zur sicheren Übertragung von Informationen für alle genutzten Übertragungswege sind festzulegen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.1.2 -->
Genutzte Netzdienste sind im Netz-/Netzdienste-Register ({{LINK:REG-NET}}) identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04, Krypto-/Schlüsselverwaltung siehe {{LINK:VA-07}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.1.2-elev -->
Bei hohem Schutzbedarf werden Informationen mindestens transportverschlüsselt oder gleichwertig geschützt übertragen; {{#if FLAG_VERY_HIGH_PROTECTION}}bei sehr hohem Schutzbedarf erfolgt eine Inhaltsverschlüsselung.{{/if}}
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Verfahren/Schlüssel |
| {{ROLE_ISB}} | Zulässige Algorithmen |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-07}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R08}}, {{LINK:R10}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R10_Betriebssicherheit.md
+598
View File
@@ -0,0 +1,598 @@
# Richtlinie Betriebssicherheit
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt den sicheren IT-Betrieb: Change, Umgebungstrennung, Malware-Schutz, Protokollierung, Schwachstellen, technische Prüfung, Netzwerksicherheit sowie Datensicherung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Änderungsmanagement (Change)
<!-- FW:REF-START ORIG:(ISA 5.2.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.9, A.8.32{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.1-M1 -->
- **[MUSS]** Informationssicherheitsanforderungen für Änderungen an Organisation, Geschäftsprozessen und IT-Systemen sind bestimmt und erfüllt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S1 -->
- **[SOLL]** Ein formales Genehmigungsverfahren ist etabliert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S2 -->
- **[SOLL]** Die möglichen Auswirkungen von Änderungen auf die Informationssicherheit werden bewertet.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S3 -->
- **[SOLL]** Änderungen mit Auswirkung auf die Informationssicherheit werden geplant und getestet.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.1-S4 -->
- **[SOLL]** Verfahren zum Rückfall (Fallback) in Fehlerfällen werden berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.1-H1 -->
- **[HOCH]** Die Einhaltung der Informationssicherheitsanforderungen wird während und nach den Änderungen überprüft. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.9-1 -->
- **[ISO A.8.9]** Konfigurationen von Hardware, Software, Diensten und Netzen sind festzulegen, zu dokumentieren, umzusetzen, zu überwachen und zu überprüfen.
<!-- REQ A.8.32-1 -->
- **[ISO A.8.32]** Änderungen an informationsverarbeitenden Einrichtungen und Systemen sind einem Änderungsmanagement zu unterziehen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.1 -->
Änderungen durchlaufen ein formales Change-Verfahren (siehe {{LINK:VA-04}}) mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.1-elev -->
Bei hohem Schutzbedarf wird die Einhaltung der Informationssicherheitsanforderungen während und nach der Änderung verifiziert.
{{/if}}
### 3.2 Trennung von Entwicklungs-, Test- und Produktivsystemen
<!-- FW:REF-START ORIG:(ISA 5.2.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.31{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.2-M1 -->
- **[MUSS]** Die IT-Systeme wurden einer Risikobewertung unterzogen, um die Notwendigkeit ihrer Trennung in Entwicklungs-, Test- und Produktivsysteme zu bestimmen.
<!-- REQ 5.2.2-M2 -->
- **[MUSS]** Eine Segmentierung ist auf Basis der Ergebnisse der Risikoanalyse umgesetzt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.2-S1 -->
- **[SOLL]** Die Anforderungen an Entwicklungs- und Testumgebungen sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.31-1 -->
- **[ISO A.8.31]** Entwicklungs-, Test- und Produktionsumgebungen sind zu trennen und zu schützen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.2 -->
Auf Basis einer Risikobewertung sind Entwicklung, Test und Produktion getrennt betrieben und segmentiert; Anforderungen an Entwicklungs-/Testumgebungen sind bestimmt und erfüllt, Produktivdaten werden dort nur anonymisiert/pseudonymisiert genutzt.
### 3.3 Schutz vor Schadsoftware
<!-- FW:REF-START ORIG:(ISA 5.2.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.7, A.8.23{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.3-M1 -->
- **[MUSS]** Anforderungen zum Schutz vor Schadsoftware sind bestimmt.
<!-- REQ 5.2.3-M2 -->
- **[MUSS]** Technische und organisatorische Maßnahmen zum Schutz vor Schadsoftware sind definiert und umgesetzt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S1 -->
- **[SOLL]** Unnötige Netzwerkdienste sind deaktiviert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S2 -->
- **[SOLL]** Der Zugriff auf Netzwerkdienste ist durch geeignete Schutzmaßnahmen auf das Notwendige beschränkt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S3 -->
- **[SOLL]** Schutzsoftware gegen Schadsoftware ist installiert und wird regelmäßig automatisch aktualisiert (z. B. Virenscanner).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S4 -->
- **[SOLL]** Empfangene Dateien und Software werden vor der Ausführung automatisch auf Schadsoftware geprüft (On-Access-Scan).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S5 -->
- **[SOLL]** Der gesamte Datenbestand aller Systeme wird regelmäßig auf Schadsoftware geprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S6 -->
- **[SOLL]** Über zentrale Gateways übertragene Daten (z. B. E-Mail, Internet, Fremdnetze) werden automatisch durch Schutzsoftware geprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S7 -->
- **[SOLL]** Maßnahmen, die verhindern, dass Schutzsoftware durch Nutzer deaktiviert oder verändert wird, sind definiert und umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.3-S8 -->
- **[SOLL]** Für IT-Systeme ohne Schutzsoftware sind alternative Maßnahmen umgesetzt (z. B. besondere Resilienz, wenige Dienste, keine aktiven Nutzer, Netzisolation).
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.7-1 -->
- **[ISO A.8.7]** Schutz vor Schadsoftware ist umzusetzen und durch angemessene Awareness der Benutzer zu unterstützen.
<!-- REQ A.8.23-1 -->
- **[ISO A.8.23]** Der Zugriff auf externe Webseiten ist zu steuern, um die Exposition gegenüber schädlichen Inhalten zu reduzieren.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.3 -->
Malware-Schutz ist über {{TECH_MALWARE}} auf allen Endpunkten und Servern umgesetzt (BL-OPS-03); Signaturen/Engines aktualisieren sich {{MALWARE_UPDATE}}, On-Access- und regelmäßige Vollscans sowie Gateway-Prüfungen (E-Mail/Internet) sind aktiv. Unnötige Netzwerkdienste sind deaktiviert, der Zugriff ist beschränkt, das Deaktivieren der Schutzsoftware ist unterbunden; für Systeme ohne Schutzsoftware greifen alternative Maßnahmen (Isolation).
### 3.4 Protokollierung und Auswertung
<!-- FW:REF-START ORIG:(ISA 5.2.4) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.15, A.8.16{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.4-M1 -->
- **[MUSS]** Informationssicherheitsanforderungen an den Umgang mit Ereignisprotokollen sind bestimmt und erfüllt.
<!-- REQ 5.2.4-M2 -->
- **[MUSS]** Sicherheitsrelevante Anforderungen an die Protokollierung von Aktivitäten von Administratoren und Nutzern sind bestimmt und erfüllt.
<!-- REQ 5.2.4-M3 -->
- **[MUSS]** Die eingesetzten IT-Systeme werden hinsichtlich der Notwendigkeit der Protokollierung bewertet.
<!-- REQ 5.2.4-M4 -->
- **[MUSS]** Bei Nutzung externer IT-Dienste werden Informationen zu den Überwachungsmöglichkeiten eingeholt und in der Bewertung berücksichtigt.
<!-- REQ 5.2.4-M5 -->
- **[MUSS]** Ereignisprotokolle werden regelmäßig auf Richtlinienverstöße und auffällige Probleme geprüft, unter Einhaltung der zulässigen rechtlichen und organisatorischen Vorgaben.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S1 -->
- **[SOLL]** Ein Verfahren zur Eskalation relevanter Ereignisse an die verantwortliche Stelle ist definiert und etabliert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S2 -->
- **[SOLL]** Ereignisprotokolle (Inhalt und Metadaten) sind gegen Veränderung geschützt (z. B. durch eine dedizierte Umgebung).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.4-S3 -->
- **[SOLL]** Eine angemessene Überwachung und Aufzeichnung aller informationssicherheitsrelevanten Aktionen im Netzwerk ist etabliert.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.4-H1 -->
- **[HOCH]** Sicherheitsrelevante Anforderungen an den Umgang mit Ereignisprotokollen, z. B. vertragliche Anforderungen, sind bestimmt und umgesetzt. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.4-H2 -->
- **[HOCH]** Ereignisse zu Auf- und Abbau von Fernzugriffssitzungen (z. B. Fernwartung) werden protokolliert. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.4-V1 -->
- **[SEHR HOCH]** Protokollierung jedes Zugriffs auf Daten mit sehr hohem Schutzbedarf, soweit technisch machbar und rechtlich/organisatorisch zulässig. (C, I)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.15-1 -->
- **[ISO A.8.15]** Protokolle über Aktivitäten, Ausnahmen, Fehler und Ereignisse sind zu erzeugen, zu speichern, zu schützen und auszuwerten.
<!-- REQ A.8.16-1 -->
- **[ISO A.8.16]** Netze, Systeme und Anwendungen sind auf anomales Verhalten zu überwachen und mögliche Vorfälle zu bewerten.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.4 -->
Sicherheitsrelevante Ereignisse (inkl. Administrator-/Nutzeraktivitäten) werden nach bestimmten und bewerteten Anforderungen zentral über {{TECH_SIEM}} protokolliert und regelmäßig auf Verstöße ausgewertet (BL-OPS-04); bei externen Diensten werden Überwachungsmöglichkeiten berücksichtigt. Protokolle sind manipulationsgeschützt, Aufbewahrung {{LOG_RETENTION}}, ein Eskalationsverfahren ist etabliert (siehe {{LINK:VA-13}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.4-elev -->
Bei hohem Schutzbedarf sind zusätzliche (z. B. vertragliche) Protokollanforderungen umgesetzt und Fernzugriffssitzungen werden protokolliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf wird jeder Zugriff auf entsprechende Daten protokolliert, soweit technisch/rechtlich zulässig.{{/if}}
{{/if}}
### 3.5 Umgang mit Schwachstellen
<!-- FW:REF-START ORIG:(ISA 5.2.5) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.5{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.8{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.5-M1 -->
- **[MUSS]** Informationen über technische Schwachstellen der eingesetzten IT-Systeme werden erhoben (z. B. Herstellerinfos, System-Audits, CVE-Datenbank).
<!-- REQ 5.2.5-M2 -->
- **[MUSS]** Potenziell betroffene IT-Systeme und Software werden identifiziert und das durch die Schwachstelle verursachte Risiko wird bewertet.
<!-- REQ 5.2.5-M3 -->
- **[MUSS]** Risiken aus Schwachstellen werden behandelt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S1 -->
- **[SOLL]** Ein angemessenes Patch-Management ist definiert und umgesetzt (z. B. Patch-Test und -Installation).
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S2 -->
- **[SOLL]** Risikominimierende Maßnahmen werden bei Bedarf umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.5-S3 -->
- **[SOLL]** Die erfolgreiche Installation von Patches wird in geeigneter Weise verifiziert.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.8-1 -->
- **[ISO A.8.8]** Informationen über technische Schwachstellen sind zu beschaffen, die Betroffenheit zu bewerten und geeignete Maßnahmen zu ergreifen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.5 -->
Schwachstelleninformationen werden erhoben (Herstellerinfos, CVE, Scans BL-OPS-02), betroffene Systeme identifiziert, das Risiko bewertet und nach BL-OPS-01 risikoorientiert über Patch-/Change-Management (siehe {{LINK:VA-06}}) behandelt (kritisch {{PATCH_SLA_CRIT}}); die erfolgreiche Installation wird verifiziert und im {{TOOL_TICKET}} nachverfolgt, risikominimierende Maßnahmen greifen bei Bedarf.
### 3.6 Technische Überprüfung von IT-Systemen
<!-- FW:REF-START ORIG:(ISA 5.2.6) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.6{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.34{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.6-M1 -->
- **[MUSS]** Anforderungen an die Prüfung (Audit) von IT-Systemen oder -Diensten sind bestimmt.
<!-- REQ 5.2.6-M2 -->
- **[MUSS]** Der Umfang der Systemprüfung wird rechtzeitig festgelegt.
<!-- REQ 5.2.6-M3 -->
- **[MUSS]** System- oder Dienstprüfungen werden mit Betreiber und Nutzern der IT-Systeme/-Dienste abgestimmt.
<!-- REQ 5.2.6-M4 -->
- **[MUSS]** Die Ergebnisse von System-/Dienstprüfungen werden nachvollziehbar gespeichert und der zuständigen Leitung berichtet.
<!-- REQ 5.2.6-M5 -->
- **[MUSS]** Aus den Ergebnissen werden Maßnahmen abgeleitet und in angemessener Frist umgesetzt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S1 -->
- **[SOLL]** System- und Dienstprüfungen werden unter Berücksichtigung möglicher Sicherheitsrisiken (z. B. Störungen) geplant.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S2 -->
- **[SOLL]** Regelmäßige System- oder Dienstprüfungen werden durchgeführt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.6-S3 -->
- **[SOLL]** Innerhalb einer angemessenen Frist nach Abschluss der Prüfung wird ein Bericht erstellt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.6-H1 -->
- **[HOCH]** Für kritische IT-Systeme/-Dienste wurden zusätzliche Prüfanforderungen identifiziert und werden erfüllt (z. B. dienstspezifische Tests/Werkzeuge und/oder manuelle Penetrationstests, risikobasierte Intervalle). (A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.6-V1 -->
- **[SEHR HOCH]** IT-Systeme und -Dienste werden regelmäßig auf Schwachstellen gescannt. Für nicht scanbare Systeme/Dienste sind geeignete Schutzmaßnahmen umzusetzen. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.34-1 -->
- **[ISO A.8.34]** Audit-Tests und ähnliche Prüftätigkeiten an Produktivsystemen sind zu planen und zu vereinbaren, um Beeinträchtigungen zu vermeiden.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.6 -->
Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft (siehe {{LINK:VA-06}}). Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.6-elev -->
Bei hohem Schutzbedarf werden für kritische Systeme zusätzliche Prüfungen (Penetrationstests {{PENTEST_FREQ}}, BL-OPS-08) durchgeführt. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Systeme regelmäßig auf Schwachstellen gescannt bzw. nicht scanbare durch geeignete Maßnahmen geschützt.{{/if}}
{{/if}}
### 3.7 Netzwerksicherheit
<!-- FW:REF-START ORIG:(ISA 5.2.7) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.7{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.20, A.8.22{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.7-M1 -->
- **[MUSS]** Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und erfüllt.
<!-- REQ 5.2.7-M2 -->
- **[MUSS]** Anforderungen an die Netzsegmentierung sind bestimmt und erfüllt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.7-S1 -->
- **[SOLL]** Verfahren für das Management und die Steuerung von Netzwerken sind definiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.7-S2 -->
- **[SOLL]** Für eine risikobasierte Netzsegmentierung werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.7-H1 -->
- **[HOCH]** Erweiterte Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und umgesetzt. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.20-1 -->
- **[ISO A.8.20]** Netze und Netzwerkgeräte sind zu sichern, zu verwalten und zu steuern, um Informationen zu schützen.
<!-- REQ A.8.22-1 -->
- **[ISO A.8.22]** Gruppen von Informationsdiensten, Nutzern und Systemen sind in Netzen zu segmentieren.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.7 -->
Das Netzwerk ist nach Schutzbedarf risikobasiert segmentiert (BL-NET-01), zugangskontrolliert und nach außen über Firewall (Default-Deny, BL-NET-02) abgesichert; Management-/Steuerungsverfahren und ein aktueller Netzplan/Segmentierungskonzept werden im Netz-/Netzdienste-Register ({{LINK:REG-NET}}) gepflegt.{{#if FLAG_OT_USED}} Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert.{{/if}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.7-elev -->
Bei hohem Schutzbedarf sind erweiterte Anforderungen an Netzmanagement und -steuerung bestimmt und umgesetzt.
{{/if}}
### 3.8 Datensicherung und Wiederherstellung
<!-- FW:REF-START ORIG:(ISA 5.2.9) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.2.9{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.13{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.2.9-M1 -->
- **[MUSS]** Backup-Konzepte existieren für relevante IT-Systeme. Angemessene Schutzmaßnahmen für Vertraulichkeit, Integrität und Verfügbarkeit der Datensicherungen werden berücksichtigt.
<!-- REQ 5.2.9-M2 -->
- **[MUSS]** Wiederherstellungskonzepte existieren für relevante IT-Dienste.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.2.9-S1 -->
- **[SOLL]** Für jeden relevanten IT-Dienst existiert ein Backup- und Wiederherstellungskonzept. Abhängigkeiten zwischen IT-Diensten und die Reihenfolge der Wiederherstellung werden berücksichtigt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.9-H1 -->
- **[HOCH]** Backup- und Wiederherstellungskonzepte werden methodisch in regelmäßigen Abständen überprüft. (A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.2.9-H2 -->
- **[HOCH]** Die grundsätzliche Wiederherstellbarkeit wird berücksichtigt und getestet (z. B. Stichprobentests, Testsysteme). (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V1 -->
- **[SEHR HOCH]** (Zusätzliche) Backups werden über Offline-Verfahren, unveränderliche (immutable) Backups oder eine isolierte IAM-Lösung durchgeführt. (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V2 -->
- **[SEHR HOCH]** Wiederherstellungsverfahren werden methodisch in regelmäßigen Abständen technisch getestet. (I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.2.9-V3 -->
- **[SEHR HOCH]** Geografische Redundanz wird in Backup- und Wiederherstellungskonzepten berücksichtigt. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.13-1 -->
- **[ISO A.8.13]** Sicherungskopien von Informationen, Software und Systemen sind gemäß Sicherungskonzept zu erstellen und regelmäßig zu testen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.9 -->
Backup- und Wiederherstellungskonzepte für relevante IT-Dienste bestehen (Schutz von Vertraulichkeit/Integrität/Verfügbarkeit, Abhängigkeiten und Reihenfolge berücksichtigt); Sicherung erfolgt nach Schema {{BACKUP_SCHEME}} über {{TECH_BACKUP}} (BL-OPS-05), Aufbewahrung {{BACKUP_RETENTION}}, Wiederherstellung geregelt und getestet (siehe {{LINK:VA-05}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.2.9-elev -->
Bei hohem Schutzbedarf werden Konzepte methodisch überprüft und die Wiederherstellbarkeit getestet. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf erfolgen zusätzliche Offline-/immutable-Backups, methodische technische Restore-Tests und geografische Redundanz.{{/if}}
{{/if}}
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.9 Bedrohungsinformationen
*Anforderungsbezug:* ISO/IEC 27001 A.5.7
**Anforderung**
<!-- REQ A.5.7-1 -->
- **[ISO A.5.7]** Informationen über Bedrohungen sind zu sammeln und auszuwerten, um Bedrohungsinformationen (Threat Intelligence) zu erzeugen und zu nutzen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-THREATINTEL -->
Informationen über Bedrohungen werden regelmäßig aus benannten Quellen ({{THREAT_INTEL_SOURCES}}) bezogen und von {{ROLE_IT_LEAD}} auf Relevanz für die eigenen Systeme und Dienste bewertet. Relevante Erkenntnisse führen zu Maßnahmen im Schwachstellen- und Patchmanagement ({{LINK:VA-06}}), zu Anpassungen der Überwachung ({{LINK:VA-13}}) oder zu einer erneuten Risikobeurteilung. Bewertung und abgeleitete Maßnahmen werden im {{TOOL_TICKET}} dokumentiert.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.10 Dokumentierte Betriebsabläufe
*Anforderungsbezug:* ISO/IEC 27001 A.5.37
**Anforderung**
<!-- REQ A.5.37-1 -->
- **[ISO A.5.37]** Betriebsabläufe für informationsverarbeitende Einrichtungen sind zu dokumentieren und den betroffenen Personen bereitzustellen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-BETRIEBSABLAEUFE -->
Betriebsabläufe für informationsverarbeitende Einrichtungen sind dokumentiert und den ausführenden Personen zugänglich. Abgedeckt sind Inbetriebnahme und Konfiguration, Betrieb und Überwachung, Datensicherung, Behandlung von Störungen, Wartung sowie Außerbetriebnahme. Die Dokumentation wird bei Änderungen über das Änderungsmanagement (BL-OPS-09) aktualisiert und mindestens {{POLICY_REVIEW_CYCLE}} auf Aktualität geprüft. Verantwortlich: {{ROLE_IT_LEAD}}.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.11 Kapazitätssteuerung
*Anforderungsbezug:* ISO/IEC 27001 A.8.6
**Anforderung**
<!-- REQ A.8.6-1 -->
- **[ISO A.8.6]** Ressourcen sind zu überwachen und die Kapazität ist an den aktuellen und erwarteten Bedarf anzupassen.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-KAPAZITAET -->
Die Auslastung der maßgeblichen Ressourcen — Rechenleistung, Arbeitsspeicher, Speicherplatz, Netzbandbreite, Lizenzen sowie personelle Kapazität im IT-Betrieb — wird {{CAPACITY_REVIEW_FREQ}} überwacht (BL-OPS-11). Überschrittene Schwellenwerte lösen eine Meldung aus; der künftige Bedarf wird bei Projekten und wesentlichen Änderungen berücksichtigt. Kapazitätsengpässe mit Auswirkung auf die Verfügbarkeitsanforderungen werden als Risiko erfasst und behandelt.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.12 Verhinderung von Datenabfluss
*Anforderungsbezug:* ISO/IEC 27001 A.8.12
**Anforderung**
<!-- REQ A.8.12-1 -->
- **[ISO A.8.12]** Maßnahmen zur Verhinderung von Datenlecks sind auf Systeme, Netze und Geräte anzuwenden, die sensible Informationen verarbeiten.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-DLP -->
Für Systeme, Netze und Geräte, die schutzbedürftige Informationen verarbeiten, sind Maßnahmen gegen unbefugten Abfluss umgesetzt (BL-OPS-12); abgedeckt sind mindestens {{DLP_SCOPE}}. Die Maßnahmen richten sich nach der Klassifizierung ({{LINK:R02}}): Regeln zur Weitergabe, Kontrolle der Übertragungswege, Beschränkung von Wechseldatenträgern (BL-EP-03) sowie Protokollierung und Auswertung auffälliger Übertragungen (BL-OPS-04). Erkannte Verstöße werden als Sicherheitsereignis behandelt ({{LINK:VA-01}}); bei personenbezogener Auswertung werden Mitbestimmungsrechte gewahrt.
{{/if}}
<!-- FW:ISO-SECTION-END -->
<!-- FW:ISO-SECTION-START -->
{{#if FLAG_FW_ISO27001}}
### 3.13 Uhrzeitsynchronisation
*Anforderungsbezug:* ISO/IEC 27001 A.8.17
**Anforderung**
<!-- REQ A.8.17-1 -->
- **[ISO A.8.17]** Die Uhren der Systeme sind auf zugelassene Zeitquellen zu synchronisieren.
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL ISO-ZEITSYNC -->
Die Systemuhren aller protokollierenden Systeme werden auf {{NTP_SOURCES}} synchronisiert (BL-OPS-10). Abweichungen werden überwacht und gemeldet. Eine einheitliche Zeitbasis und Zeitzone ist Voraussetzung für die Auswertbarkeit der Protokolle ({{LINK:VA-13}}) und für die Beweissicherung bei Vorfällen.
{{/if}}
<!-- FW:ISO-SECTION-END -->
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Sicherer IT-Betrieb |
| {{ROLE_ISB}} | Überwachung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-04}}, {{LINK:VA-05}}, {{LINK:VA-06}}, {{LINK:VA-13}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R04}}, {{LINK:R08}}, {{LINK:R11}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md
+219
View File
@@ -0,0 +1,219 @@
# Richtlinie Sichere Systembeschaffung und Entwicklung
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Informationssicherheit bei Beschaffung und Entwicklung, Anforderungen an Netzdienste sowie Rückgabe und sichere Löschung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Sicherheit bei Beschaffung und Entwicklung
<!-- FW:REF-START ORIG:(ISA 5.3.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.4, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.30, A.8.33{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.1-M1 -->
- **[MUSS]** Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
<!-- REQ 5.3.1-M2 -->
- **[MUSS]** Die mit Beschaffung oder Erweiterung von IT-Diensten und -Komponenten verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
<!-- REQ 5.3.1-M3 -->
- **[MUSS]** Informationssicherheitsanforderungen im Zusammenhang mit Änderungen an entwickelten IT-Diensten werden berücksichtigt.
<!-- REQ 5.3.1-M4 -->
- **[MUSS]** Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S1 -->
- **[SOLL]** Anforderungsspezifikationen werden erstellt; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S2 -->
- **[SOLL]** Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S3 -->
- **[SOLL]** Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S4 -->
- **[SOLL]** Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden (ggf. Anonymisierung/Pseudonymisierung); dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.1-S5 -->
- **[SOLL]** Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten für Tests genutzt werden.
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 5.3.1-V1 -->
- **[SEHR HOCH]** Die Sicherheit zweckgebauter oder wesentlich angepasster Software wird bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (z. B. Penetrationstest). (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.4-1 -->
- **[ISO A.8.4]** Der Lese- und Schreibzugriff auf Quellcode, Entwicklungswerkzeuge und Softwarebibliotheken ist angemessen zu steuern.
<!-- REQ A.8.25-1 -->
- **[ISO A.8.25]** Regeln für einen sicheren Entwicklungslebenszyklus von Software und Systemen sind festzulegen und anzuwenden.
<!-- REQ A.8.26-1 -->
- **[ISO A.8.26]** Informationssicherheitsanforderungen sind bei Entwicklung oder Beschaffung von Anwendungen zu ermitteln, zu spezifizieren und zu berücksichtigen.
<!-- REQ A.8.27-1 -->
- **[ISO A.8.27]** Grundsätze für die Entwicklung sicherer Systeme sind festzulegen, zu dokumentieren und anzuwenden.
<!-- REQ A.8.28-1 -->
- **[ISO A.8.28]** Grundsätze für sichere Programmierung sind auf die Softwareentwicklung anzuwenden.
<!-- REQ A.8.29-1 -->
- **[ISO A.8.29]** Sicherheitstests sind in den Entwicklungs- und Abnahmeprozess zu integrieren.
<!-- REQ A.8.30-1 -->
- **[ISO A.8.30]** Ausgelagerte Systementwicklung ist zu steuern, zu überwachen und zu überprüfen.
<!-- REQ A.8.33-1 -->
- **[ISO A.8.33]** Testinformationen sind sorgfältig auszuwählen, zu schützen und zu verwalten.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.3.1 -->
Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikation, Prüfung und Abnahmetests unter Sicherheitsaspekten erfolgen nach dem Verfahren Sichere Beschaffung/Entwicklung & Abnahme ({{LINK:VA-16}}); Produktivsetzung erst nach Prüfung im {{TOOL_TICKET}}. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan) gemäß {{LINK:VA-16}}.{{/if}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.3.1-elev -->
{{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf wird die Sicherheit zweckgebauter oder wesentlich angepasster Software bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (Penetrationstest).{{/if}}
{{/if}}
### 3.2 Anforderungen an Netzdienste
<!-- FW:REF-START ORIG:(ISA 5.3.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.21{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.2-M1 -->
- **[MUSS]** Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S1 -->
- **[SOLL]** Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S2 -->
- **[SOLL]** Die Anforderungen werden in Form von SLAs vereinbart.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.2-S3 -->
- **[SOLL]** Angemessene Redundanzlösungen sind umgesetzt.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 5.3.2-H1 -->
- **[HOCH]** Verfahren zur Überwachung der Qualität des Netzverkehrs (z. B. Traffic-Flow-Analysen, Verfügbarkeitsmessungen) sind definiert und werden durchgeführt. (A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.8.21-1 -->
- **[ISO A.8.21]** Sicherheitsmechanismen, Dienstgüten und Anforderungen an Netzwerkdienste sind zu identifizieren, umzusetzen und zu überwachen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.3.2 -->
Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen bestimmt, in SLAs vereinbart und über ein Verfahren umgesetzt; angemessene Redundanzen bestehen.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 5.3.2-elev -->
Bei hohem Schutzbedarf werden Verfahren zur Überwachung der Netzverkehrsqualität (Traffic-Flow-Analysen, Verfügbarkeitsmessungen) definiert und durchgeführt.
{{/if}}
### 3.3 Rückgabe und sichere Löschung
<!-- FW:REF-START ORIG:(ISA 5.3.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.11, A.7.14, A.8.10{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.3-S1 -->
- **[SOLL]** Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.11-1 -->
- **[ISO A.5.11]** Beschäftigte und externe Nutzer haben bei Beendigung des Beschäftigungs-/Vertragsverhältnisses alle in ihrem Besitz befindlichen Assets zurückzugeben.
<!-- REQ A.7.14-1 -->
- **[ISO A.7.14]** Betriebsmittel mit Speichermedien sind vor Entsorgung oder Wiederverwendung sicher zu bereinigen (Datenlöschung).
<!-- REQ A.8.10-1 -->
- **[ISO A.8.10]** In Systemen und auf Medien gespeicherte Informationen sind zu löschen, sobald sie nicht mehr benötigt werden.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.3.3 -->
Rückgabe und sichere Löschung/Vernichtung von Informationen und Assets (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt, vertraglich vereinbart, an Änderungen angepasst und werden nachgewiesen (Löschprotokoll).
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Beschaffung/Entwicklung |
| {{ROLE_ISB}} | Sicherheitsanforderungen |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R02}}, {{LINK:R10}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R12_Cloud-KI-und-externe-IT-Dienste.md
+117
View File
@@ -0,0 +1,117 @@
# Richtlinie Cloud-, KI- und externe IT-Dienste
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt den Schutz in ausgelagerten/geteilten externen IT-Diensten (Cloud) sowie beim Einsatz von KI-/GenAI-Diensten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Schutz in geteilten externen IT-Diensten
<!-- FW:REF-START ORIG:(ISA 5.3.4) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 5.3.4{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.23{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.4-M1 -->
- **[MUSS]** Eine wirksame Trennung (z. B. Mandantentrennung) verhindert den Zugriff unbefugter Nutzer anderer Organisationen auf eigene Informationen.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.4-S1 -->
- **[SOLL]** Das Trennungskonzept des Anbieters ist dokumentiert und an Änderungen angepasst; dabei werden die einschlägigen Aspekte berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.23-1 -->
- **[ISO A.5.23]** Prozesse für Beschaffung, Nutzung, Verwaltung und Beendigung von Cloud-Diensten sind entsprechend den Informationssicherheitsanforderungen festzulegen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.3.4 -->
Bei geteilten externen IT-Diensten wird eine wirksame Mandantentrennung gefordert und vertraglich zugesichert; das Trennungskonzept des Anbieters wird dokumentiert und bei Änderungen aktualisiert.{{#if FLAG_CLOUD_USED}} Cloud-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; die Freigaben werden im Register externe IT-/Cloud-/KI-Dienste ({{LINK:REG-EXT-SERVICES}}) geführt (siehe {{LINK:VA-11}}).{{/if}}
{{#if FLAG_AI_USED}}
### 3.2 Nutzung von KI-/GenAI-Diensten (Ergänzung R12, nicht ISA)
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 5.3.4-KI-M1 -->
- **[MUSS]** Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutzt.
<!-- REQ 5.3.4-KI-M2 -->
- **[MUSS]** Die Eingabe vertraulicher oder personenbezogener Informationen in nicht freigegebene KI-Dienste ist untersagt; zulässige Datenklassen je Dienst sind definiert.
<!-- REQ 5.3.4-KI-M3 -->
- **[MUSS]** Bei freigegebenen KI-Diensten ist geklärt und vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.4-KI-S1 -->
- **[SOLL]** Ergebnisse von KI-Diensten werden vor geschäftskritischer Verwendung geprüft (Human-in-the-Loop); der KI-Einsatz wird dokumentiert und regulatorische Anforderungen (z. B. EU AI Act) berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.3.4-KI -->
Der Einsatz von KI-/GenAI-Diensten ist geregelt; nur von {{ROLE_ISB}} freigegebene Dienste (geführt im Register externe IT-/Cloud-/KI-Dienste {{LINK:REG-EXT-SERVICES}}) dürfen genutzt werden (siehe {{LINK:VA-11}}). Zulässige Datenklassen je Dienst sind definiert, die Eingabe vertraulicher/personenbezogener Daten in nicht freigegebene Dienste ist untersagt; bei Freigabe ist vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden. KI-Ergebnisse werden vor kritischer Verwendung geprüft (Human-in-the-Loop), der Einsatz dokumentiert und der EU AI Act berücksichtigt.
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Freigabe/Steuerung |
| {{ROLE_IT_LEAD}} | Technische Absicherung |
| Fachbereiche | Nutzung freigegebener Dienste |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-11}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R09}}, {{LINK:R11}}, {{LINK:R13}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R13_Lieferanten-und-Dienstleistersteuerung.md
+250
View File
@@ -0,0 +1,250 @@
# Richtlinie Lieferanten- und Dienstleistersteuerung
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt Sicherstellung der Informationssicherheit bei Lieferanten, Vertraulichkeitsvereinbarungen und Abgrenzung der Verantwortlichkeiten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Informationssicherheit bei Lieferanten
<!-- FW:REF-START ORIG:(ISA 6.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.19, A.5.22{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.1-M1 -->
- **[MUSS]** Auftragnehmer und Partner werden einer Sicherheitsrisikobewertung unterzogen.
<!-- REQ 6.1.1-M2 -->
- **[MUSS]** Ein angemessenes Informationssicherheitsniveau wird durch vertragliche Vereinbarungen mit Auftragnehmern und Partnern sichergestellt.
<!-- REQ 6.1.1-M3 -->
- **[MUSS]** Sofern zutreffend, werden vertragliche Vereinbarungen mit Auftraggebern/Kunden an Auftragnehmer und Partner weitergegeben.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.1-S1 -->
- **[SOLL]** Auftragnehmer und Partner sind vertraglich verpflichtet, Anforderungen an ein angemessenes Informationssicherheitsniveau an ihre Unterauftragnehmer weiterzugeben.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.1-S2 -->
- **[SOLL]** Leistungsberichte und Dokumente von Auftragnehmern und Partnern werden geprüft.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H1 -->
- **[HOCH]** Es wird nachgewiesen, dass das Informationssicherheitsniveau des Lieferanten dem Schutzbedarf angemessen ist (z. B. geprüfter Fragebogen/Selbstauskunft, Attestierung, Zertifikat, Lieferantenaudit). (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H2 -->
- **[HOCH]** Der Grad der Erfüllung geforderter Nachweise durch den Lieferanten wird dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.1-H3 -->
- **[HOCH]** Die Einhaltung vertraglicher Vereinbarungen durch den Lieferanten wird geprüft, dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 6.1.1-V1 -->
- **[SEHR HOCH]** Das angemessene Informationssicherheitsniveau sollte durch ein Drittparteien-Audit (angemessenes TISAX-Label o. Ä.) oder ein angemessenes Lieferantenaudit nachgewiesen werden. Ohne Audit muss die Leitung eine risikobasierte Entscheidung zur Fortführung treffen; ein Nachweis dieser Entscheidung existiert. (C, I, A)
{{/if}}
{{#if FLAG_VERY_HIGH_PROTECTION}}
<!-- REQ 6.1.1-V2 -->
- **[SEHR HOCH]** Vertragliche Verpflichtungen gegenüber Kunden zur Transparenz von Lieferkettenrisiken werden erfüllt. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.19-1 -->
- **[ISO A.5.19]** Prozesse zur Steuerung der Informationssicherheitsrisiken aus Lieferantenbeziehungen sind festzulegen und umzusetzen.
<!-- REQ A.5.22-1 -->
- **[ISO A.5.22]** Die Informationssicherheit von Lieferantenleistungen ist regelmäßig zu überwachen, zu überprüfen und Änderungen sind zu steuern.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 6.1.1 -->
Auftragnehmer/Partner werden einer Sicherheitsrisikobewertung (BL-SUP-01) unterzogen und vertraglich auf ein angemessenes Informationssicherheitsniveau (inkl. Weitergabe an Unterauftragnehmer und Kundenanforderungen) verpflichtet; das Lieferantenverzeichnis wird im ISMS-Tool ({{TOOL_NAME}}) geführt, Leistungsberichte werden geprüft (siehe {{LINK:VA-10}}).
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 6.1.1-elev -->
Bei hohem Schutzbedarf wird das Sicherheitsniveau des Lieferanten nachgewiesen (Selbstauskunft/Attest/Zertifikat/Audit) und die Einhaltung dokumentiert, regelmäßig und bei Änderungen überwacht. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf erfolgt der Nachweis über ein Drittparteien-Audit (TISAX o. Ä.) oder eine dokumentierte risikobasierte Leitungsentscheidung; Transparenzpflichten zu Lieferkettenrisiken werden erfüllt.{{/if}}
{{/if}}
### 3.2 Vertraulichkeitsvereinbarungen
<!-- FW:REF-START ORIG:(ISA 6.1.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.20{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.2-M1 -->
- **[MUSS]** Die Vertraulichkeitsanforderungen sind bestimmt und erfüllt.
<!-- REQ 6.1.2-M2 -->
- **[MUSS]** Anforderungen und Verfahren zur Anwendung von Vertraulichkeitsvereinbarungen sind allen Personen bekannt, die schutzbedürftige Informationen weitergeben.
<!-- REQ 6.1.2-M3 -->
- **[MUSS]** Gültige Vertraulichkeitsvereinbarungen werden vor der Weitergabe schutzbedürftiger Informationen abgeschlossen.
<!-- REQ 6.1.2-M4 -->
- **[MUSS]** Die Anforderungen und Verfahren zur Nutzung von Vertraulichkeitsvereinbarungen und zum Umgang mit schutzbedürftigen Informationen werden regelmäßig überprüft.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S1 -->
- **[SOLL]** Vorlagen für Vertraulichkeitsvereinbarungen sind vorhanden und auf rechtliche Anwendbarkeit geprüft.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S2 -->
- **[SOLL]** Vertraulichkeitsvereinbarungen umfassen beteiligte Personen/Organisationen, Art der Informationen, Gegenstand, Gültigkeitsdauer und Verantwortlichkeiten der verpflichteten Partei.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S3 -->
- **[SOLL]** Vertraulichkeitsvereinbarungen enthalten Regelungen zum Umgang mit schutzbedürftigen Informationen über die Vertragsbeziehung hinaus.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S4 -->
- **[SOLL]** Möglichkeiten zum Nachweis der Einhaltung (z. B. Prüfung durch unabhängige Dritte oder Auditrechte) sind definiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.2-S5 -->
- **[SOLL]** Ein Prozess zur Überwachung der Gültigkeitsdauer temporärer Vertraulichkeitsvereinbarungen und zur rechtzeitigen Verlängerung ist definiert und umgesetzt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.20-1 -->
- **[ISO A.5.20]** Relevante Informationssicherheitsanforderungen sind mit jedem Lieferanten zu vereinbaren und vertraglich festzuhalten.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 6.1.2 -->
Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (Ablauf siehe {{LINK:VA-10}}) (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.
### 3.3 Abgrenzung der Verantwortlichkeiten
<!-- FW:REF-START ORIG:(ISA 6.1.3) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 6.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.21{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 6.1.3-M1 -->
- **[MUSS]** Die betroffenen IT-Dienste sind identifiziert.
<!-- REQ 6.1.3-M2 -->
- **[MUSS]** Die für den IT-Dienst relevanten Sicherheitsanforderungen sind bestimmt.
<!-- REQ 6.1.3-M3 -->
- **[MUSS]** Die für die Umsetzung der Anforderung verantwortliche Organisation ist definiert und sich ihrer Verantwortung bewusst.
<!-- REQ 6.1.3-M4 -->
- **[MUSS]** Mechanismen für geteilte Verantwortlichkeiten sind spezifiziert und umgesetzt.
<!-- REQ 6.1.3-M5 -->
- **[MUSS]** Die verantwortliche Organisation erfüllt ihre jeweiligen Verantwortlichkeiten.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.3-S1 -->
- **[SOLL]** Bei IT-Diensten ist die Konfiguration auf Basis der notwendigen Sicherheitsanforderungen konzipiert, umgesetzt und dokumentiert.
{{/if}}
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 6.1.3-S2 -->
- **[SOLL]** Das verantwortliche Personal ist angemessen geschult.
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H1 -->
- **[HOCH]** Eine Liste der betroffenen IT-Dienste und der jeweils verantwortlichen IT-Dienstleister existiert. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H2 -->
- **[HOCH]** Die Anwendbarkeit der ISA-Controls wurde bewertet und dokumentiert. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H3 -->
- **[HOCH]** Die Dienstkonfiguration ist in die regelmäßigen Sicherheitsbewertungen einbezogen. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H4 -->
- **[HOCH]** Es wird nachgewiesen, dass die IT-Dienstleister ihre Verantwortung erfüllen. (C, I, A)
{{/if}}
{{#if FLAG_HIGH_PROTECTION}}
<!-- REQ 6.1.3-H5 -->
- **[HOCH]** Die Integration in lokale Schutzmaßnahmen (z. B. sichere Authentifizierungsmechanismen) ist etabliert und dokumentiert. (C, I, A)
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.21-1 -->
- **[ISO A.5.21]** Prozesse zum Umgang mit Informationssicherheitsrisiken in der IKT-Produkt- und Dienstleistungs-Lieferkette sind festzulegen und umzusetzen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 6.1.3 -->
Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt (siehe {{LINK:VA-10}}); betroffene IT-Dienste und Dienstleister sind im Register externe IT-/Cloud-/KI-Dienste ({{LINK:REG-EXT-SERVICES}}) geführt. Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 6.1.3-elev -->
Bei hohem Schutzbedarf existiert eine Liste der IT-Dienste und verantwortlichen Dienstleister, die Anwendbarkeit der ISA-Controls ist bewertet/dokumentiert, die Dienstkonfiguration ist Teil regelmäßiger Sicherheitsbewertungen, die Verantwortungserfüllung wird nachgewiesen und die Integration in lokale Schutzmaßnahmen ist dokumentiert.
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Lieferantensteuerung |
| Einkauf | Vertragliche Einbindung |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Zugehörige Verfahren: {{LINK:VA-10}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R01}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/richtlinien/R14_Compliance-und-Datenschutz.md
+129
View File
@@ -0,0 +1,129 @@
# Richtlinie Compliance und Datenschutz
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
Diese Richtlinie regelt die Einhaltung regulatorischer/vertraglicher Vorgaben sowie den Schutz personenbezogener Daten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
## 2. Geltungsbereich
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
### 3.1 Regulatorische und vertragliche Compliance
<!-- FW:REF-START ORIG:(ISA 7.1.1) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 7.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.31, A.5.32, A.5.33{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 7.1.1-M1 -->
- **[MUSS]** Rechtliche, regulatorische und vertragliche Vorgaben mit Relevanz für die Informationssicherheit werden regelmäßig bestimmt.
<!-- REQ 7.1.1-M2 -->
- **[MUSS]** Richtlinien zur Einhaltung der Vorgaben sind definiert, umgesetzt und den verantwortlichen Personen kommuniziert.
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 7.1.1-S1 -->
- **[SOLL]** Die Integrität von Aufzeichnungen entsprechend rechtlichen, regulatorischen und vertraglichen Vorgaben sowie Geschäftsanforderungen wird berücksichtigt.
{{/if}}
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.31-1 -->
- **[ISO A.5.31]** Rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen an die Informationssicherheit sind zu identifizieren, zu dokumentieren und aktuell zu halten.
<!-- REQ A.5.32-1 -->
- **[ISO A.5.32]** Geeignete Verfahren zum Schutz geistiger Eigentumsrechte sind umzusetzen.
<!-- REQ A.5.33-1 -->
- **[ISO A.5.33]** Aufzeichnungen sind vor Verlust, Zerstörung, Fälschung sowie unbefugtem Zugriff und unbefugter Veröffentlichung zu schützen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 7.1.1 -->
Relevante rechtliche, regulatorische und vertragliche Anforderungen werden regelmäßig bestimmt und in einem Compliance-/Rechtsregister im ISMS-Tool ({{TOOL_NAME}}) erfasst; Richtlinien zur Einhaltung sind definiert, umgesetzt und den Verantwortlichen kommuniziert, die Integrität von Aufzeichnungen wird berücksichtigt.
{{#if FLAG_PERSONAL_DATA}}
### 3.2 Schutz personenbezogener Daten
<!-- FW:REF-START ORIG:(ISA 7.1.2) -->
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 7.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.34{{/if}}
<!-- FW:REF-END -->
**Anforderung**
<!-- FW:TISAX-REQ-START -->
{{#if FLAG_FW_TISAX}}
{{#if FLAG_FW_ISO27001}}*Anforderungen nach VDA ISA 2027:*{{/if}}
<!-- REQ 7.1.2-M1 -->
- **[MUSS]** Rechtliche und vertragliche Informationssicherheitsanforderungen an Verfahren und Prozesse bei der Verarbeitung personenbezogener Daten sind bestimmt.
<!-- REQ 7.1.2-M2 -->
- **[MUSS]** Regelungen zur Einhaltung rechtlicher und vertraglicher Anforderungen an den Schutz personenbezogener Daten sind definiert und den beteiligten Personen bekannt.
<!-- REQ 7.1.2-M3 -->
- **[MUSS]** Prozesse und Verfahren zum Schutz personenbezogener Daten sind im Informationssicherheits-Managementsystem berücksichtigt.
{{/if}}
<!-- FW:TISAX-REQ-END -->
<!-- FW:ISO-REQ-START -->
{{#if FLAG_FW_ISO27001}}
{{#if FLAG_FW_TISAX}}*Anforderungen nach ISO/IEC 27001:*{{/if}}
<!-- REQ A.5.34-1 -->
- **[ISO A.5.34]** Anforderungen an den Schutz personenbezogener Daten (PII) sind zu identifizieren und gemäß geltenden Vorgaben zu erfüllen.
{{/if}}
<!-- FW:ISO-REQ-END -->
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 7.1.2 -->
Rechtliche und vertragliche Anforderungen an die Verarbeitung personenbezogener Daten (DSGVO) sind bestimmt; Regelungen sind definiert, den Beteiligten bekannt und im ISMS berücksichtigt. {{ROLE_DPO}} ist eingebunden, das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt, TOM und Löschkonzepte (BL-DEL-01) sind geregelt; Rechtsregister-Review, Löschfristen und Betroffenenrechte werden nach dem Datenschutz-/Compliance-Pflegeverfahren ({{LINK:VA-18}}) bearbeitet.
{{/if}}
## 4. Verbindlichkeit
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_ISB}} | Compliance-Register |
| {{ROLE_DPO}} | Datenschutz |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
## 8. Verwandte Dokumente
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:L00}}, {{LINK:R03}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/variables.schema.json
+379
View File
@@ -0,0 +1,379 @@
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ISMS-Vorlagenpaket v2 – Wizard-Variablen (VDA ISA 2027 / Information Security)",
"description": "Single Source of Truth aller Wizard-Variablen. Konvention: UPPER_SNAKE_CASE, Platzhalter {{NAME}}. Feature-Flags steuern {{#if FLAG_X}}-Bloecke. Der Programmierer generiert die Wizard-Eingaben aus diesem Schema.",
"version": "2.0",
"type": "object",
"properties": {
"ORG_NAME": {
"type": "string",
"title": "Organisation (voller Name)",
"example": "Muster GmbH"
},
"ORG_SHORT": {
"type": "string",
"title": "Organisation (Kurzname)",
"example": "Muster"
},
"ISMS_SCOPE": {
"type": "string",
"title": "Geltungsbereich (Kurzlabel)",
"example": "IT & Entwicklung Werk Nord"
},
"ISMS_SCOPE_DESCRIPTION": {
"type": "string",
"title": "Geltungsbereich (Beschreibung)"
},
"ROLE_MANAGEMENT": {
"type": "string",
"title": "Oberste Leitung",
"default": "Geschäftsführung"
},
"ROLE_ISB": {
"type": "string",
"title": "Informationssicherheitsbeauftragte(r) / CISO",
"default": "Informationssicherheitsbeauftragte(r) (ISB)"
},
"ROLE_IT_LEAD": {
"type": "string",
"title": "IT-Leitung",
"default": "IT-Leitung"
},
"ROLE_HR_LEAD": {
"type": "string",
"title": "Personalleitung",
"default": "Personalleitung"
},
"ROLE_DPO": {
"type": "string",
"title": "Datenschutzbeauftragte(r)",
"default": "Datenschutzbeauftragte(r) (DSB)"
},
"DOC_VERSION": {
"type": "string",
"title": "Version",
"default": "1.0"
},
"DOC_DATE": {
"type": "string",
"title": "Datum",
"format": "date"
},
"DOC_STATUS": {
"type": "string",
"title": "Status",
"enum": [
"Entwurf",
"In Freigabe",
"Freigegeben"
],
"default": "Entwurf"
},
"TOOL_NAME": {
"type": "string",
"title": "Name des ISMS-Tools",
"default": "ISMS-Tool"
},
"REVIEW_CYCLE": {
"type": "string",
"title": "Revisionszyklus (Freitext)",
"default": "jährlich"
},
"TECH_MFA": {
"type": "string",
"title": "MFA-Lösung",
"default": "die eingesetzte MFA-Lösung"
},
"TECH_MALWARE": {
"type": "string",
"title": "Malware-Schutz-Lösung",
"default": "die eingesetzte Endpoint-Schutzlösung"
},
"TECH_BACKUP": {
"type": "string",
"title": "Backup-Lösung",
"default": "die eingesetzte Backup-Lösung"
},
"TECH_SIEM": {
"type": "string",
"title": "Logging/SIEM-Lösung",
"default": "die zentrale Protokollierung"
},
"TECH_MDM": {
"type": "string",
"title": "MDM-Lösung",
"default": "das eingesetzte MDM"
},
"TECH_VPN": {
"type": "string",
"title": "VPN/Remote-Access-Lösung",
"default": "VPN"
},
"TECH_CRYPTO": {
"type": "string",
"title": "Krypto-Vorgabe/Standard",
"default": "aktuelle BSI-/Branchenempfehlungen"
},
"TOOL_TICKET": {
"type": "string",
"title": "Ticket-/Workflow-System (Dokumentationsort)",
"default": "Ticketsystem"
},
"TOOL_IAM": {
"type": "string",
"title": "Verzeichnis-/IAM-System",
"default": "Entra ID / Active Directory"
},
"PW_MIN_LENGTH": {
"type": "string",
"title": "Passwort-Mindestlänge (BL-IAM-01)",
"default": "12"
},
"PW_COMPLEXITY": {
"type": "string",
"title": "Passwort-Komplexität (BL-IAM-01)",
"default": "Komplexität aus mind. 3 von 4 Zeichenkategorien"
},
"PW_ROTATION": {
"type": "string",
"title": "Passwort-Rotation (BL-IAM-01)",
"default": "keine feste Zwangsrotation, Wechsel anlassbezogen bei Verdacht"
},
"MFA_SCOPE": {
"type": "string",
"title": "MFA-Geltungsbereich (BL-IAM-02)",
"default": "alle Fernzugriffe, administrative Zugänge und Cloud-Dienste"
},
"SESSION_TIMEOUT": {
"type": "string",
"title": "Sitzungs-Timeout (BL-IAM-03)",
"default": "15 Min. Inaktivität (privilegiert), 8 Std. (Standard)"
},
"ACCOUNT_LOCKOUT": {
"type": "string",
"title": "Kontosperrung (BL-IAM-04)",
"default": "temporäre Sperre nach 10 Fehlversuchen"
},
"RECERT_FREQ": {
"type": "string",
"title": "Rezertifizierung (BL-IAM-05)",
"default": "halbjährlich"
},
"TLS_MIN": {
"type": "string",
"title": "Mindest-TLS (BL-CRY-01)",
"default": "TLS 1.2 (Empfehlung TLS 1.3)"
},
"CRYPTO_ALGO": {
"type": "string",
"title": "Zulässige Algorithmen (BL-CRY-02)",
"default": "AES-256, RSA ≥ 3072 / ECC ≥ 256, SHA-256 oder stärker"
},
"PATCH_SLA_CRIT": {
"type": "string",
"title": "Patch-SLA kritisch (BL-OPS-01)",
"default": "innerhalb von 72 Stunden"
},
"PATCH_SLA_HIGH": {
"type": "string",
"title": "Patch-SLA hoch (BL-OPS-01)",
"default": "innerhalb von 14 Tagen"
},
"PATCH_SLA_STD": {
"type": "string",
"title": "Patch-SLA standard (BL-OPS-01)",
"default": "im regulären monatlichen Patchzyklus"
},
"VULN_SCAN_FREQ": {
"type": "string",
"title": "Schwachstellenscan (BL-OPS-02)",
"default": "monatlich"
},
"MALWARE_UPDATE": {
"type": "string",
"title": "Malware-Update (BL-OPS-03)",
"default": "mehrmals täglich automatisch"
},
"LOG_RETENTION": {
"type": "string",
"title": "Log-Aufbewahrung (BL-OPS-04)",
"default": "90 Tage, risikoabhängig bis 12 Monate"
},
"BACKUP_SCHEME": {
"type": "string",
"title": "Backup-Schema (BL-OPS-05)",
"default": "3-2-1 (3 Kopien, 2 Medien, 1 offline/ausgelagert)"
},
"BACKUP_RETENTION": {
"type": "string",
"title": "Backup-Aufbewahrung (BL-OPS-05)",
"default": "täglich 30 Tage, monatlich 12 Monate"
},
"BACKUP_TEST_FREQ": {
"type": "string",
"title": "Wiederherstellungstest (BL-OPS-06)",
"default": "jährlich"
},
"PENTEST_FREQ": {
"type": "string",
"title": "Penetrationstest (BL-OPS-08)",
"default": "jährlich"
},
"FLAG_INCLUDE_SHOULD": {
"type": "boolean",
"title": "SOLL-Anforderungen einbeziehen (Reifegrad 3 = true)",
"default": true
},
"FLAG_HIGH_PROTECTION": {
"type": "boolean",
"title": "Zusatzanforderungen HOHER Schutzbedarf einbeziehen",
"default": false
},
"FLAG_VERY_HIGH_PROTECTION": {
"type": "boolean",
"title": "Zusatzanforderungen SEHR HOHER Schutzbedarf einbeziehen",
"default": false
},
"FLAG_ELEVATED_PROTECTION": {
"type": "boolean",
"title": "Abgeleitet: HIGH ODER VERY_HIGH aktiv (vom Wizard gesetzt = FLAG_HIGH_PROTECTION || FLAG_VERY_HIGH_PROTECTION)",
"default": false
},
"FLAG_CLOUD_USED": {
"type": "boolean",
"title": "Cloud-Dienste im Einsatz",
"default": true
},
"FLAG_AI_USED": {
"type": "boolean",
"title": "KI-/GenAI-Dienste im Einsatz",
"default": true
},
"FLAG_OT_USED": {
"type": "boolean",
"title": "Produktions-/OT-Umgebung vorhanden",
"default": false
},
"FLAG_DEV_INHOUSE": {
"type": "boolean",
"title": "Eigene Software-Entwicklung",
"default": false
},
"FLAG_MOBILE_WORK": {
"type": "boolean",
"title": "Mobiles Arbeiten / Homeoffice zugelassen",
"default": true
},
"FLAG_MOBILE_DEVICES": {
"type": "boolean",
"title": "Mobile Endgeräte / Datenträger im Einsatz",
"default": true
},
"FLAG_CRYPTO_PKI": {
"type": "boolean",
"title": "Eigene PKI / Zertifikatsverwaltung",
"default": false
},
"FLAG_EXTERNAL_IT": {
"type": "boolean",
"title": "Externe IT-Dienstleister genutzt",
"default": true
},
"FLAG_PERSONAL_DATA": {
"type": "boolean",
"title": "Verarbeitung personenbezogener Daten",
"default": true
},
"FLAG_CUSTOMER_SYSTEMS": {
"type": "boolean",
"title": "Zugriff auf Kundensysteme (z.B. OEM)",
"default": false
},
"FLAG_PROTOTYPE_PROTECTION": {
"type": "boolean",
"title": "Prüfziel Prototypenschutz aktiv (Kapitel 8.x)",
"default": false
},
"FLAG_ISB_INTERNAL": {
"type": "boolean",
"title": "ISB intern besetzt",
"default": true
},
"FLAG_ISB_EXTERNAL": {
"type": "boolean",
"title": "ISB extern besetzt (externer Dienstleister)",
"default": false
},
"FLAG_FW_TISAX": {
"type": "boolean",
"title": "Framework: TISAX / VDA ISA anwenden",
"default": true
},
"FLAG_FW_ISO27001": {
"type": "boolean",
"title": "Framework: ISO/IEC 27001 anwenden",
"default": false
},
"POLICY_REVIEW_CYCLE": {
"type": "string",
"title": "Prüfzyklus Leitlinie/Richtlinien",
"example": "jährlich",
"default": "jährlich"
},
"MGMT_REVIEW_CYCLE": {
"type": "string",
"title": "Turnus Managementbewertung",
"example": "jährlich",
"default": "jährlich"
},
"RISK_REVIEW_CYCLE": {
"type": "string",
"title": "Turnus Risikobeurteilung",
"example": "jährlich",
"default": "jährlich"
},
"RECORDS_RETENTION": {
"type": "string",
"title": "Aufbewahrung abgelöster Dokumentfassungen",
"example": "3 Jahre",
"default": "3 Jahre"
},
"AUTHORITY_CONTACTS": {
"type": "string",
"title": "Relevante Behörden/Meldestellen",
"example": "Datenschutz-Aufsichtsbehörde, Polizei (ZAC), BSI/CERT-Bund",
"default": "Datenschutz-Aufsichtsbehörde, Polizei (ZAC), BSI/CERT-Bund"
},
"THREAT_INTEL_SOURCES": {
"type": "string",
"title": "Quellen für Bedrohungsinformationen",
"example": "CERT-Bund-Warnmeldungen, Herstellerhinweise, CVE-Feeds",
"default": "CERT-Bund-Warnmeldungen, Herstellerhinweise, CVE-Feeds"
},
"CAPACITY_REVIEW_FREQ": {
"type": "string",
"title": "Turnus Kapazitätsüberwachung",
"example": "monatlich",
"default": "monatlich"
},
"NTP_SOURCES": {
"type": "string",
"title": "Zugelassene Zeitquellen",
"example": "zwei unabhängige, vertrauenswürdige NTP-Quellen",
"default": "zwei unabhängige, vertrauenswürdige NTP-Quellen"
},
"DLP_SCOPE": {
"type": "string",
"title": "Abgedeckte Kanäle gegen Datenabfluss",
"example": "E-Mail, Wechseldatenträger, Cloud-Speicher",
"default": "E-Mail, Wechseldatenträger, Cloud-Speicher"
}
},
"required": [
"ORG_NAME",
"ISMS_SCOPE",
"ISMS_SCOPE_DESCRIPTION",
"DOC_VERSION",
"DOC_DATE"
]
}
seed/isms-vorlagenpaket-v2/verfahren/VA-01_Incident-Response-und-Meldeverfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Incident-Response- und Meldeverfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-01) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.6.1-M1, 1.6.1-M2, 1.6.2-M1, 1.6.2-M2, 1.6.2-S1, 1.6.2-S2, A.5.24-1, A.5.25-1, A.5.26-1, A.5.27-1, A.5.28-1, A.6.8-1 | POLICY R04 -->
## 1. Zweck
Dieses Verfahren regelt Meldung, Bewertung, Behandlung und Nachbereitung von Informationssicherheitsvorfällen. Es operationalisiert die zugehörige Richtlinie ({{LINK:R04}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Meldung eines Sicherheitsereignisses (Mitarbeitende, Technik/Monitoring, Externe) über den definierten Meldeweg.
## 4. Eingaben
- Meldung/Alarm mit Kurzbeschreibung
- Betroffene Systeme/Informationen (Asset-Inventar)
- Klassifizierung/Schutzbedarf
## 5. Ablauf
1. Ereignis melden: Meldung über das {{TOOL_TICKET}} bzw. E-Mail an {{ROLE_ISB}} erfassen.
2. Triage & Klassifizierung: Relevanz, Schweregrad und Kategorie festlegen.
3. Eindämmung: Sofortmaßnahmen zur Begrenzung des Schadens einleiten.
4. Behebung & Wiederherstellung: Ursache beseitigen, Normalbetrieb herstellen.
5. Meldepflichten prüfen: Kunden/OEM, Behörden, bei personenbezogenen Daten {{ROLE_DPO}} (72-Stunden-Frist).
6. Dokumentation & Lessons Learned: Vorfall abschließen, Verbesserungsmaßnahmen ableiten.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Ereignis melden | Meldende Person | {{ROLE_ISB}} | - | - |
| 2 | Triage & Klassifizierung | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Eindämmung | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} |
| 4 | Behebung & Wiederherstellung | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 5 | Meldepflichten prüfen | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | {{ROLE_DPO}} | - |
| 6 | Dokumentation & Lessons Learned | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | {{ROLE_MANAGEMENT}} |
## 7. Ergebnis & Nachweis
Dokumentierter, abgeschlossener Vorfall im {{TOOL_TICKET}}; abgeleitete Maßnahmen im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Zeit bis Ersterfassung (Time-to-Detect/Acknowledge)
- Zeit bis Behebung (Time-to-Resolve)
- Anteil fristgerechter Meldungen
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R04}}
- {{LINK:VA-02}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-02_IT-Notfall-und-Wiederanlaufverfahren.md
+72
View File
@@ -0,0 +1,72 @@
# IT-Notfall- und Wiederanlaufverfahren (BCM)
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-02) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.6.3-M1, 1.6.3-S1, 5.2.8-M1, 5.2.8-S1, A.5.29-1, A.5.30-1, A.8.14-1 | POLICY R04 -->
## 1. Zweck
Dieses Verfahren regelt die Aufrechterhaltung und Wiederherstellung kritischer IT-Dienste bei Ausfall oder Krise. Es operationalisiert die zugehörige Richtlinie ({{LINK:R04}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Ausfall kritischer IT-Dienste, Notfall oder Krisenfall (Eskalation aus VA-01).
## 4. Eingaben
- Liste kritischer IT-Dienste mit RTO/RPO
- Wiederanlaufpläne
- Backup-Status (VA-05)
## 5. Ablauf
1. Notfall feststellen & einstufen: Ausmaß bewerten, ggf. Krisenstab einberufen.
2. Kommunikation aktivieren: Interne/externe Stakeholder informieren.
3. Wiederanlauf priorisieren: Dienste nach RTO/RPO in Reihenfolge bringen.
4. Wiederherstellung durchführen: Systeme/Daten aus Backup (VA-05) wiederherstellen.
5. Rückkehr zum Normalbetrieb bestätigen & dokumentieren.
6. Nachbereitung & Test-Update: Plan aktualisieren, {{BACKUP_TEST_FREQ}} üben.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Notfall feststellen & einstufen | {{ROLE_IT_LEAD}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 2 | Kommunikation aktivieren | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | - | Mitarbeitende |
| 3 | Wiederanlauf priorisieren | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Wiederherstellung durchführen | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Rückkehr zum Normalbetrieb bestätigen & | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | {{ROLE_MANAGEMENT}} |
| 6 | Nachbereitung & Test-Update | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Wiederhergestellte Dienste; dokumentierter Notfall/Test im ISMS-Tool ({{TOOL_NAME}}); aktualisierte Wiederanlaufpläne. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Einhaltung RTO/RPO
- Erfolgsquote Wiederherstellungstests
- Aktualität der Notfallpläne
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R04}}
- {{LINK:VA-01}}
- {{LINK:VA-05}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-03_Berechtigungsverfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Berechtigungsverfahren (Joiner/Mover/Leaver und Rezertifizierung)
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-03) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 4.1.1-S1, 4.1.3-M1, 4.2.1-M1, 4.2.1-M2, 4.2.1-S1, A.5.15-1, A.5.16-1, A.5.17-1, A.5.18-1, A.8.18-1, A.8.2-1, A.8.3-1, A.8.5-1 | POLICY R08 -->
## 1. Zweck
Dieses Verfahren regelt Beantragung, Genehmigung, Änderung, Entzug und regelmäßige Überprüfung von Zugriffsrechten. Es operationalisiert die zugehörige Richtlinie ({{LINK:R08}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Eintritt, Rollenwechsel oder Austritt einer Person; Berechtigungsantrag; fällige Rezertifizierung.
## 4. Eingaben
- Personalmeldung (HR)
- Rollen-/Rechtekatalog (RBAC)
- Bestehende Berechtigungen aus dem zentralen Verzeichnis ({{TOOL_IAM}})
## 5. Ablauf
1. Antrag erfassen: Zugang/Recht im {{TOOL_TICKET}} beantragen (Joiner/Mover).
2. Fachliche Genehmigung: Erforderlichkeit nach Minimalprinzip prüfen und freigeben.
3. Umsetzung: Rechte rollenbasiert im zentralen Verzeichnis ({{TOOL_IAM}}) setzen.
4. Leaver/Änderung: Bei Austritt/Wechsel Rechte unverzüglich entziehen/anpassen.
5. Rezertifizierung ({{RECERT_FREQ}}, BL-IAM-05): Owner bestätigen/entziehen Rechte.
6. Privilegierte Konten: gesondert prüfen und protokollieren (BL-IAM-06).
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Antrag erfassen | Vorgesetzte/Fachbereich | {{ROLE_IT_LEAD}} | - | - |
| 2 | Fachliche Genehmigung | Fachbereich/Dateneigentümer | Fachbereich/Dateneigentümer | {{ROLE_ISB}} | - |
| 3 | Umsetzung | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | Antragsteller |
| 4 | Leaver/Änderung | {{ROLE_IT_LEAD}} | {{ROLE_HR_LEAD}} | - | - |
| 5 | Rezertifizierung ({{RECERT_FREQ}}, BL-IAM-05) | Fachbereich/Dateneigentümer | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 6 | Privilegierte Konten | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Dokumentierte Anträge/Genehmigungen im {{TOOL_TICKET}}; aktueller Berechtigungsstand im zentralen Verzeichnis ({{TOOL_IAM}}); Rezertifizierungsnachweis. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil fristgerecht entzogener Leaver-Rechte
- Rezertifizierungsquote
- Zahl verwaister/privilegierter Konten
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R08}}
- {{LINK:VA-01}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-04_Change-und-Patch-Management-Verfahren.md
+71
View File
@@ -0,0 +1,71 @@
# Change- und Patch-Management-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-04) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.1-M1, 5.2.5-M1, A.7.13-1, A.8.19-1, A.8.32-1, A.8.9-1 | POLICY R10 -->
## 1. Zweck
Dieses Verfahren regelt geplante Änderungen an IT-Systemen sowie das risikoorientierte Einspielen von Patches. Es operationalisiert die zugehörige Richtlinie ({{LINK:R10}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Änderungsbedarf, verfügbarer Patch oder identifizierte Schwachstelle (VA-06).
## 4. Eingaben
- Change-/Patch-Antrag
- Risikoeinschätzung
- Patch-SLA (BL-OPS-01)
## 5. Ablauf
1. Change beantragen & klassifizieren (Standard/Normal/Notfall) im {{TOOL_TICKET}}.
2. Risiko-/Auswirkungsbewertung inkl. Rollback-Plan.
3. Genehmigung durch CAB/verantwortliche Rolle.
4. Test in getrennter Umgebung (BL-OPS, R10).
5. Umsetzung in Produktion gemäß Patch-SLA (kritisch {{PATCH_SLA_CRIT}}).
6. Verifikation & Dokumentation des Ergebnisses im {{TOOL_TICKET}}.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Change beantragen & klassifizieren (Stan | Antragsteller | {{ROLE_IT_LEAD}} | - | - |
| 2 | Risiko-/Auswirkungsbewertung inkl. Rollb | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 3 | Genehmigung durch CAB/verantwortliche Ro | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Test in getrennter Umgebung (BL-OPS, R10 | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Umsetzung in Produktion gemäß Patch-SLA | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | Betroffene |
| 6 | Verifikation & Dokumentation des Ergebni | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Dokumentierte, genehmigte und verifizierte Änderung/Patch im {{TOOL_TICKET}}. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Patch-Compliance je Kritikalität
- Anteil erfolgreicher Changes (ohne Rollback)
- Durchlaufzeit kritischer Patches
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R10}}
- {{LINK:VA-06}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-05_Backup-und-Restore-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Backup- und Restore-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-05) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.9-M1, 5.2.9-M2, 5.2.9-S1, A.8.13-1 | POLICY R10 -->
## 1. Zweck
Dieses Verfahren regelt Datensicherung, Aufbewahrung und Wiederherstellung nach dem {{BACKUP_SCHEME}}-Schema. Es operationalisiert die zugehörige Richtlinie ({{LINK:R10}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Regulärer Sicherungslauf; Wiederherstellungsbedarf; geplanter Restore-Test.
## 4. Eingaben
- Sicherungsplan je System
- Klassifizierung/RPO
- Backup-Ziele ({{TECH_BACKUP}})
## 5. Ablauf
1. Sicherung durchführen: automatisierte Backups gemäß {{BACKUP_SCHEME}} (BL-OPS-05).
2. Überwachung: Erfolg/Fehler prüfen, Fehlläufe nachverfolgen ({{TOOL_TICKET}}).
3. Schutz & Auslagerung: 1 Kopie offline/immutable, Aufbewahrung {{BACKUP_RETENTION}}.
4. Restore-Anforderung bearbeiten (bei Bedarf/Notfall, VA-02).
5. Wiederherstellungstest ({{BACKUP_TEST_FREQ}}, BL-OPS-06) durchführen & dokumentieren.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Sicherung durchführen | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Überwachung | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 3 | Schutz & Auslagerung | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Restore-Anforderung bearbeiten (bei Beda | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | Anforderer | - |
| 5 | Wiederherstellungstest ({{BACKUP_TEST_FREQ}}) | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Protokollierte Sicherungen; dokumentierte Restore-Tests; Nachweis im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Backup-Erfolgsquote
- Erfolgsquote Restore-Tests
- Einhaltung RPO
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R10}}
- {{LINK:VA-02}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-06_Schwachstellenmanagement-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Schwachstellenmanagement-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-06) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.5-M1, 5.2.5-S1, 5.2.6-M1, A.8.8-1 | POLICY R10 -->
## 1. Zweck
Dieses Verfahren regelt Erkennung, Bewertung, Behandlung und technische Prüfung von Schwachstellen. Es operationalisiert die zugehörige Richtlinie ({{LINK:R10}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Regelmäßiger Scan ({{VULN_SCAN_FREQ}}), Sicherheitsmeldung/CVE, Penetrationstest ({{PENTEST_FREQ}}).
## 4. Eingaben
- Scan-/Testberichte
- Asset-Inventar & Kritikalität
- Patch-SLA (BL-OPS-01)
## 5. Ablauf
1. Identifikation: Schwachstellen-Scan {{VULN_SCAN_FREQ}} (BL-OPS-02) und Meldungen auswerten.
2. Bewertung & Priorisierung nach Kritikalität und Exponierung.
3. Behandlung anstoßen: Patch/Change (VA-04) oder kompensierende Maßnahme.
4. Technische Prüfung: Härtung (BL-OPS-07) und Penetrationstests ({{PENTEST_FREQ}}, BL-OPS-08).
5. Nachverfolgung & Verifikation der Behebung im {{TOOL_TICKET}}.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Identifikation | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Bewertung & Priorisierung nach Kritikali | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 3 | Behandlung anstoßen | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Technische Prüfung | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | Externer Dienstleister | - |
| 5 | Nachverfolgung & Verifikation der Behebu | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Nachverfolgte Schwachstellen mit Behandlungsstatus im {{TOOL_TICKET}}; Testberichte. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Mittlere Behebungszeit je Kritikalität
- Offene kritische Schwachstellen
- Scan-Abdeckung
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R10}}
- {{LINK:VA-04}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-07_Kryptokonzept-und-Schluesselverwaltung.md
+69
View File
@@ -0,0 +1,69 @@
# Kryptokonzept und Schlüsselverwaltung
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-07) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.1.1-M1, 5.1.1-M2, 5.1.1-S1, 5.1.2-M1, 5.1.2-S1, A.8.24-1 | POLICY R09 -->
## 1. Zweck
Dieses Verfahren regelt den Einsatz kryptografischer Verfahren und die Verwaltung von Schlüsseln über den Lebenszyklus. Es operationalisiert die zugehörige Richtlinie ({{LINK:R09}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Neuer Bedarf an Verschlüsselung/Zertifikaten; Schlüsselerneuerung/-sperrung; Änderung des Stands der Technik.
## 4. Eingaben
- Zulässige Algorithmen (BL-CRY-02)
- Schutzbedarf der Daten
- Zertifikats-/Schlüsselbestand
## 5. Ablauf
1. Bedarf & Verfahren festlegen: zulässige Algorithmen {{CRYPTO_ALGO}} (BL-CRY-02) wählen.
2. Schlüssel/Zertifikate erzeugen und sicher verteilen (BL-CRY-05).
3. Speicherung & Zugriffsschutz (getrennte Aufbewahrung, {{#if FLAG_CRYPTO_PKI}}PKI, {{/if}}Berechtigungen).
4. Übertragungsschutz sicherstellen: mindestens {{TLS_MIN}} (BL-CRY-01).
5. Erneuerung/Sperrung/Vernichtung dokumentieren.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Bedarf & Verfahren festlegen | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 2 | Schlüssel/Zertifikate erzeugen und siche | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 3 | Speicherung & Zugriffsschutz (getrennte | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Übertragungsschutz sicherstellen | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Erneuerung/Sperrung/Vernichtung dokument | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Dokumentiertes Kryptokonzept; nachvollziehbarer Schlüssel-/Zertifikatslebenszyklus. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil konformer Verfahren/Algorithmen
- Ablaufende Zertifikate ohne Erneuerung
- Abdeckung Transportverschlüsselung
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R09}}
- {{LINK:VA-04}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-08_Asset-und-Klassifizierungsverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Asset- und Klassifizierungsverfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-08) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.3.1-M1, 1.3.1-M2, 1.3.1-S1, 1.3.2-M1, 1.3.2-M2, 1.3.2-S1, A.5.10-1, A.5.11-1, A.5.12-1, A.5.13-1, A.5.9-1, A.7.10-1, A.7.14-1, A.8.10-1 | POLICY R02 -->
## 1. Zweck
Dieses Verfahren regelt Erfassung, Owner-Zuordnung, Klassifizierung und Pflege von Informationswerten und Assets. Es operationalisiert die zugehörige Richtlinie ({{LINK:R02}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Neues/geändertes Asset; Beschaffung; regelmäßige Inventurprüfung.
## 4. Eingaben
- Beschaffungs-/Änderungsmeldung
- Klassifizierungsschema
- Asset-Inventar ({{TOOL_NAME}})
## 5. Ablauf
1. Asset erfassen im Inventar ({{TOOL_NAME}}) mit Attributen.
2. Owner zuordnen.
3. Klassifizieren (Vertraulichkeit/Integrität/Verfügbarkeit) durch Owner.
4. Handhabungsvorgaben je Schutzklasse anwenden (Kennzeichnung/Speicherung/Löschung BL-DEL-01).
5. Pflege & Review ({{REVIEW_CYCLE}}) auf Aktualität.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Asset erfassen im Inventar ({{TOOL_NAME}}) | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Owner zuordnen. | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | Asset Owner |
| 3 | Klassifizieren (Vertraulichkeit/Integrit | Asset Owner | Asset Owner | {{ROLE_ISB}} | - |
| 4 | Handhabungsvorgaben je Schutzklasse anwe | Asset Owner | {{ROLE_ISB}} | - | Mitarbeitende |
| 5 | Pflege & Review ({{REVIEW_CYCLE}}) auf A | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Aktuelles, klassifiziertes Asset-Inventar im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Inventar-Abdeckung
- Anteil klassifizierter Assets
- Assets ohne Owner
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R02}}
- {{LINK:VA-03}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-09_Risikomanagement-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Risikomanagement-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-09) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.4.1-M1, 1.4.1-M2, 1.4.1-M3, 1.4.1-S1, 6.1.1-1, 6.1.2-1, 6.1.3-1, 8.2-1, 8.3-1 | POLICY R03 -->
## 1. Zweck
Dieses Verfahren regelt Identifikation, Analyse, Bewertung, Behandlung und Überwachung von Informationssicherheitsrisiken. Es operationalisiert die zugehörige Richtlinie ({{LINK:R03}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Neues System/Projekt, Vorfall, Änderung, regelmäßiger Review-Zyklus.
## 4. Eingaben
- Asset-/Prozessliste
- Bewertungsskalen & Akzeptanzschwellen
- Bestehendes Risikoregister
## 5. Ablauf
1. Risiken identifizieren (Assets, Bedrohungen, Schwachstellen).
2. Analysieren & bewerten (Eintritt × Schadenshöhe) im ISMS-Tool ({{TOOL_NAME}}).
3. Behandlung festlegen (reduzieren/vermeiden/übertragen/akzeptieren) und Maßnahmen planen.
4. Restrisiko-Akzeptanz dokumentieren.
5. Überwachen & aktualisieren ({{REVIEW_CYCLE}} und anlassbezogen).
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Risiken identifizieren (Assets, Bedrohun | {{ROLE_ISB}} | {{ROLE_ISB}} | Asset/Prozessverantwortliche | - |
| 2 | Analysieren & bewerten (Eintritt × Schad | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 3 | Behandlung festlegen (reduzieren/vermeid | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | Fachbereich | - |
| 4 | Restrisiko-Akzeptanz dokumentieren. | {{ROLE_MANAGEMENT}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 5 | Überwachen & aktualisieren ({{REVIEW_CYCLE}}) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Gepflegtes Risikoregister mit Behandlungsplan und Akzeptanzentscheidungen im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil behandelter Risiken
- Überfällige Maßnahmen
- Aktualität des Risikoregisters
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R03}}
- {{LINK:VA-01}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-10_Lieferanten-Onboarding-und-Bewertung.md
+69
View File
@@ -0,0 +1,69 @@
# Lieferanten-Onboarding- und Bewertungsverfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-10) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 6.1.1-M1, 6.1.1-M2, 6.1.1-S1, 6.1.2-M1, 6.1.2-S1, 6.1.3-M1, A.5.19-1, A.5.20-1, A.5.21-1, A.5.22-1 | POLICY R13 -->
## 1. Zweck
Dieses Verfahren regelt Auswahl, sicherheitsbezogene Bewertung, vertragliche Bindung und Überwachung von Lieferanten/Dienstleistern. Es operationalisiert die zugehörige Richtlinie ({{LINK:R13}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Neuer Lieferant/Dienstleister mit Zugriff auf Informationen; Vertragsverlängerung; periodische Überprüfung.
## 4. Eingaben
- Leistungs-/Schutzbedarfsbeschreibung
- Risikoklassen (BL-SUP-01)
- NDA-/Vertragsvorlagen
## 5. Ablauf
1. Bedarf & Risikoklasse bestimmen (Schutzbedarf, Zugriff).
2. Sicherheitsbewertung (Selbstauskunft/Nachweise/TISAX) durchführen.
3. NDA & vertragliche Sicherheitsanforderungen vereinbaren.
4. Verantwortlichkeiten abgrenzen (Betrieb/Sicherheit/Meldung).
5. Ins Lieferantenverzeichnis ({{TOOL_NAME}}) aufnehmen und {{REVIEW_CYCLE}} überprüfen.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Bedarf & Risikoklasse bestimmen (Schutzbedarf, Zugriff) | Einkauf/Fachbereich | {{ROLE_ISB}} | - | - |
| 2 | Sicherheitsbewertung (Selbstauskunft/Nachweise/TISAX) | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereich | - |
| 3 | NDA & vertragliche Sicherheitsanforderun | Einkauf | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 4 | Verantwortlichkeiten abgrenzen (Betrieb/ | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 5 | Ins Lieferantenverzeichnis ({{TOOL_NAME}}) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Bewerteter, vertraglich gebundener Lieferant im Lieferantenverzeichnis ({{TOOL_NAME}}); NDA hinterlegt. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil bewerteter Lieferanten
- NDA-Abdeckung
- Überfällige Lieferantenprüfungen
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R13}}
- {{LINK:VA-11}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-11_Cloud-und-KI-Freigabeverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Cloud- und KI-Freigabeverfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-11) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.3.4-M1, 5.3.4-M2, 5.3.4-S1, 5.3.4-KI-M1, 5.3.4-KI-M2, 5.3.4-KI-M3, 5.3.4-KI-S1, A.5.23-1 | POLICY R12 -->
## 1. Zweck
Dieses Verfahren regelt Bewertung und Freigabe von Cloud- und KI-/GenAI-Diensten sowie die zulässige Nutzung. Es operationalisiert die zugehörige Richtlinie ({{LINK:R12}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Antrag zur Nutzung eines Cloud- oder KI-Dienstes.
## 4. Eingaben
- Dienstbeschreibung & Anbieterinfos
- Schutzbedarf/Datenklassen
- Vertrags-/DPA-Unterlagen
## 5. Ablauf
1. Antrag erfassen im {{TOOL_TICKET}} (Dienst, Zweck, Datenklassen).
2. Bewertung: Schutzbedarf, Datenlokation/EU, Mandantentrennung, Exit; bei KI Trainings-/Weitergabe-Ausschluss.
3. Vertrag/DPA prüfen (bei KI: Opt-out/Enterprise-Vertrag, EU AI Act).
4. Freigabe & Aufnahme in die Freigabeliste ({{TOOL_NAME}}); zulässige Datenklassen festlegen.
5. Nutzung & Kontrolle: Human-in-the-Loop bei KI, periodische Überprüfung ({{REVIEW_CYCLE}}).
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Antrag erfassen im {{TOOL_TICKET}} (Dien | Antragsteller/Fachbereich | {{ROLE_ISB}} | - | - |
| 2 | Bewertung | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | {{ROLE_DPO}} |
| 3 | Vertrag/DPA prüfen (bei KI | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | {{ROLE_DPO}} | - |
| 4 | Freigabe & Aufnahme in die Freigabeliste | {{ROLE_ISB}} | {{ROLE_ISB}} | - | Fachbereich |
| 5 | Nutzung & Kontrolle | Fachbereich | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Freigabeentscheidung und Freigabeliste im ISMS-Tool ({{TOOL_NAME}}); dokumentierte zulässige Datenklassen. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil freigegebener vs. genutzter Dienste
- Schatten-IT-Funde
- Überfällige Dienst-Reviews
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R12}}
- {{LINK:VA-10}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-12_Awareness-und-Schulungsverfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Awareness- und Schulungsverfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-12) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 2.1.3-M1, 2.1.3-S1, 7.3-1, A.6.3-1 | POLICY R05 -->
## 1. Zweck
Dieses Verfahren regelt Planung, Durchführung und Nachweis von Sensibilisierung und Schulung zur Informationssicherheit. Es operationalisiert die zugehörige Richtlinie ({{LINK:R05}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Eintritt neuer Mitarbeitender; jährlicher Schulungszyklus; anlassbezogen nach Vorfällen.
## 4. Eingaben
- Schulungsplan/Curriculum (BL-HR-01)
- Zielgruppen/Rollen
- Teilnahmestatus ({{TOOL_NAME}})
## 5. Ablauf
1. Schulungsbedarf & Zielgruppen planen (rollenspezifisch).
2. Onboarding-Schulung bei Eintritt durchführen.
3. Regelmäßige Schulung ({{REVIEW_CYCLE}}, BL-HR-01) durchführen.
4. Wirksamkeit prüfen (Phishing-Simulation) und nachschulen.
5. Teilnahme nachweisen im ISMS-Tool ({{TOOL_NAME}}).
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Schulungsbedarf & Zielgruppen planen (ro | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | - |
| 2 | Onboarding-Schulung bei Eintritt durchfü | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - | Mitarbeitende |
| 3 | Regelmäßige Schulung ({{REVIEW_CYCLE}}, | {{ROLE_ISB}} | {{ROLE_ISB}} | - | Mitarbeitende |
| 4 | Wirksamkeit prüfen (Phishing-Simulation) | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
| 5 | Teilnahme nachweisen im ISMS-Tool ({{TOOL_NAME}}) | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Dokumentierte Schulungsteilnahme und Wirksamkeitsmessung im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Schulungsquote
- Phishing-Klickrate
- Anteil rollenspezifischer Schulungen
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R05}}
- {{LINK:VA-01}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-13_Logging-und-Monitoring-Verfahren.md
+69
View File
@@ -0,0 +1,69 @@
# Logging- und Monitoring-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-13) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 5.2.4-M1, 5.2.4-S1, A.8.15-1, A.8.16-1, A.8.17-1 | POLICY R10 -->
## 1. Zweck
Dieses Verfahren regelt Erhebung, Schutz, Auswertung und Aufbewahrung sicherheitsrelevanter Protokolldaten. Es operationalisiert die zugehörige Richtlinie ({{LINK:R10}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Kontinuierlicher Betrieb; sicherheitsrelevantes Ereignis; Alarm aus {{TECH_SIEM}}.
## 4. Eingaben
- Log-Quellen/Systeme
- Aufbewahrungsvorgaben (BL-OPS-04)
- Alarmierungsregeln
## 5. Ablauf
1. Log-Quellen anbinden und zentral in {{TECH_SIEM}} erfassen (BL-OPS-04).
2. Manipulationsschutz & Aufbewahrung {{LOG_RETENTION}} sicherstellen.
3. Auswertung & Alarmierung: Regeln pflegen, Auffälligkeiten prüfen.
4. Verdachtsfall an Incident-Response (VA-01) übergeben.
5. Regelmäßige Überprüfung der Abdeckung und Regeln.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Log-Quellen anbinden und zentral in {{TECH_SIEM}} | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 2 | Manipulationsschutz & Aufbewahrung {{LOG_RETENTION}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 3 | Auswertung & Alarmierung | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 4 | Verdachtsfall an Incident-Response (VA-0 | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
| 5 | Regelmäßige Überprüfung der Abdeckung un | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Zentrale, geschützte Protokollierung mit Auswertung; Nachweis im ISMS-Tool ({{TOOL_NAME}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Log-Quellen-Abdeckung
- Mittlere Zeit bis Alarmreaktion
- Anteil auswertbarer Ereignisse
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R10}}
- {{LINK:VA-01}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-14_Personalsicherheit-Eignungspruefung.md
+71
View File
@@ -0,0 +1,71 @@
# Personalsicherheit – Eignungsprüfung & sensible Tätigkeiten
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-14) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_HR_LEAD}} |
| Freigabe durch | {{ROLE_ISB}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 2.1.1-M1, 2.1.1-M2, 2.1.1-M3, 2.1.1-S1, 2.1.1-S2, 2.1.2-M1, 2.1.2-M2, 2.1.2-S1, 2.1.2-S2, 2.1.2-S3, A.6.1-1, A.6.2-1, A.6.5-1, A.6.6-1 | POLICY R05 -->
## 1. Zweck
Dieses Verfahren regelt die Bestimmung sensibler Tätigkeiten, die Eignungs- und Identitätsprüfung bei Einstellung sowie den Umgang mit Verstößen gegen Informationssicherheits- und Vertraulichkeitspflichten. Es operationalisiert die zugehörige Richtlinie ({{LINK:R05}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}) für alle Einstellungs-, Wechsel- und Austrittsprozesse.
## 3. Auslöser
Einstellung, Wechsel in eine sensible Position, Verdacht auf Verstoß, regelmäßiger Review.
## 4. Eingaben
- Register sensibler Tätigkeiten ({{LINK:REG-SENS-ROLES}})
- Stellenbeschreibungen mit Sicherheitsanforderungen
- Personalmeldung (HR); rechtlicher Rahmen (Datenschutz/Mitbestimmung)
## 5. Ablauf
1. Sensible Tätigkeitsbereiche/Rollen im **Register sensibler Tätigkeiten ({{LINK:REG-SENS-ROLES}})** bestimmen und die geforderte Prüftiefe je Rolle festlegen.
2. Anforderungen an Positionen in Stellenbeschreibungen hinterlegen und deren Erfüllung sicherstellen.
3. Bei Einstellung die Identität verifizieren; die persönliche Eignung im rechtlich zulässigen Rahmen prüfen (Einstellungsgespräch).
4. Bei sensiblen Rollen erweiterte Prüfungen (Referenzen, Führungszeugnis) im rechtlich zulässigen Rahmen durchführen.
5. Verstöße gegen Informationssicherheits-/Vertraulichkeitspflichten nach dokumentiertem Verfahren behandeln; Nachweis in der Personalakte.
6. Sensible Rollen und Prüftiefe regelmäßig überprüfen ({{REVIEW_CYCLE}}).
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Sensible Tätigkeiten & Prüftiefe bestimmen | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | Fachbereich | - |
| 2 | Anforderungen in Stellenbeschreibungen | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | Fachbereich | - |
| 3 | Identität verifizieren / Eignung prüfen | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Erweiterte Prüfungen (sensible Rollen) | {{ROLE_HR_LEAD}} | {{ROLE_HR_LEAD}} | {{ROLE_ISB}} | - |
| 5 | Umgang mit Verstößen | {{ROLE_HR_LEAD}} | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
| 6 | Regelmäßige Überprüfung | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_HR_LEAD}} | - |
## 7. Ergebnis & Nachweis
Gepflegtes Register sensibler Tätigkeiten; dokumentierte Eignungs-/Verifizierungsnachweise in der Personalakte; dokumentierte Verstoßfälle. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Anteil sensibler Rollen mit dokumentierter Prüftiefe
- Termingerechte Identitäts-/Eignungsprüfungen
- Offene Verstoßfälle
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R05}}
- Register: {{LINK:REG-SENS-ROLES}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->
seed/isms-vorlagenpaket-v2/verfahren/VA-15_Interne-Audits-und-Compliancepruefungen.md
+72
View File
@@ -0,0 +1,72 @@
# Interne Audits & Complianceprüfungen
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-15) |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Prozessverantwortlich | {{ROLE_ISB}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
<!-- FULFILLS 1.5.1-M1, 1.5.1-M2, 1.5.1-M3, 1.5.1-M4, 1.5.1-M5, 1.5.1-S1, 1.5.2-M1, 1.5.2-M2, 1.5.2-S1, 9.2-1, A.5.35-1, A.5.36-1, A.8.34-1 | POLICY R03 -->
## 1. Zweck
Dieses Verfahren regelt Programm, Planung, Durchführung, Berichterstattung und Maßnahmenverfolgung interner Audits sowie die unabhängige Überprüfung des ISMS. Es operationalisiert die zugehörige Richtlinie ({{LINK:R03}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}) für alle Richtlinien, Verfahren und technischen Anforderungen im Geltungsbereich.
## 3. Auslöser
Auditzyklus (BL-GOV-01), wesentliche Änderungen, Anforderung durch die Leitung, Vorbefunde.
## 4. Eingaben
- Audit-Programm-Register ({{LINK:REG-AUDIT-PLAN}})
- Controls / Statement of Applicability (SoA)
- Vorherige Auditberichte & offene Maßnahmen
## 5. Ablauf
1. **Audit-Programm** im **Register ({{LINK:REG-AUDIT-PLAN}})** planen (Umfang, geprüfte Controls, Termine, Prüfer) — Turnus gemäß **BL-GOV-01**.
2. Audit **unabhängig** durchführen (Prüfer ≠ Verantwortlicher des geprüften Bereichs).
3. Befunde/Abweichungen erfassen und als Maßnahmen im ISMS-Tool ({{TOOL_NAME}}) anlegen.
4. Auditbericht an {{ROLE_MANAGEMENT}} berichten (Eingabe für die Managementbewertung).
5. Maßnahmen bis zum Abschluss nachverfolgen.
6. Unabhängige Prüfung/Assessment mindestens gemäß **BL-GOV-01** bzw. nach grundlegenden Änderungen.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Audit-Programm planen | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereiche | - |
| 2 | Audit durchführen | Auditor (unabhängig) | {{ROLE_ISB}} | geprüfter Bereich | - |
| 3 | Befunde erfassen / Maßnahmen anlegen | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereich | - |
| 4 | Bericht an Leitung | {{ROLE_ISB}} | {{ROLE_MANAGEMENT}} | - | {{ROLE_MANAGEMENT}} |
| 5 | Maßnahmen nachverfolgen | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereich | - |
| 6 | Unabhängige Prüfung | externer/unabhängiger Prüfer | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
## 7. Ergebnis & Nachweis
Auditberichte, dokumentierte Befunde/Maßnahmen und ein gepflegtes Audit-Programm ({{LINK:REG-AUDIT-PLAN}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Audit-Abdeckung der Controls
- Offene Findings / Termintreue der Maßnahmen
- Anteil fristgerecht abgeschlossener Audits
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R03}}
- Register: {{LINK:REG-AUDIT-PLAN}}
- Risikomanagement-Verfahren: {{LINK:VA-09}}
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->

Some files were not shown because too many files have changed in this diff Show More