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>
3.7 KiB
3.7 KiB
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}} |
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
- Specify security requirements (security by design) and take the protection need into account.
- 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}}
- Acceptance tests under security aspects before production deployment; approval in {{TOOL_TICKET}} (change coupling {{LINK:VA-04}}).
- Avoid or anonymise production data in tests; protect test systems appropriately.
- {{#if FLAG_DEV_INHOUSE}} For in-house development, secure coding requirements apply with code reviews and automated security tests (SAST/dependency scan).{{/if}}
- {{#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}}