Skip to main content
All downloads

Template

Connect requirements, testing and approval in the change record.

Use your existing change request or development record. The template guides requirements, testing and controlled implementation, including test information and urgent changes.

Cover of System changes and development policy template
  • Define security requirements before procurement and development.
  • Trace testing and approval to the specific version.
  • Protect test information and prepare rollback paths.

Use this template in these measures

Implementation measure

Assess and address technical vulnerabilities

Mapped requirements (1)
  • A.8.8 · Management von technischen Schwachstellen (DE)

    Supporting contribution

    The workflow connects suitable vulnerability information to actual inventory and risk, appropriate remediation and result checking. It does not replace technical assessment or remediation on the system.

Further framework mappings of this measure

  • TISAX · 5.2.5

    VDA ISA 6.0.3 · Partial contribution

    Reports, inventory matching, assessment, patch treatment and result checking support this ISA question. Actual systems, technical measures and additional requirements must be addressed operationally.

    Read the source ↗

Implementation measure

Restrict and check sensitive data flows

Mapped requirements (3)
  • A.8.3 · Einschränkung des Informationszugangs (DE)

    Supporting contribution

    Permitted content and actions derive from the leading role model, are technically restricted and are checked through authorised and unauthorised access. The workflow does not replace the full access rights lifecycle.

  • A.8.11 · Datenmaskierung (DE)

    Supporting contribution

    Purpose-based reduction and masking consider access rules, protected originals and mappings, and checked identifiability. The actual method is implemented and legally assessed for the organisation’s data flow.

  • A.8.12 · Verhinderung von Datenlecks (DE)

    Supporting contribution

    The workflow considers sensitive data and actual leakage paths, configures suitable restriction and detection, and checks alerts, exceptions and response. Technical measures and legal boundaries must be applied to the specific situation.

Implementation measure

Review and safely implement a system change

Mapped requirements (11)
  • A.8.4 · Zugang zu Quellcode (DE)

    Supporting contribution

    Step 2 separates read and write access to code, tools and libraries, including technical identities. Approval, enforcement and logged verification remain actual work in the target system.

  • A.8.19 · Installation von Software auf Betriebssystemen (DE)

    Supporting contribution

    Steps 5 and 6 connect authorised competent installation, a trusted tested release, configuration, update logging, rollback, necessary old versions and controlled external access. The installation procedure must actually be established and carried out.

  • A.8.25 · Sicherer Entwicklungslebenszyklus (DE)

    Supporting contribution

    The steps connect requirements, design, secure development, protected environments, testing, implementation and maintenance in the existing process. Appropriate technical rules and their application remain necessary.

  • A.8.26 · Anforderungen an die Anwendungssicherheit (DE)

    Supporting contribution

    Step 1 leads to described, confirmed security requirements and testable criteria before development or acquisition. Selection and acceptance must relate to the actual use.

  • A.8.27 · Sichere Systemarchitektur und technische Grundsätze (DE)

    Supporting contribution

    Step 1 checks safeguards at data flows and interfaces and how the principles work together. The suitable actual system design and decided exceptions remain necessary.

  • A.8.28 · Sicheres Coding (DE)

    Supporting contribution

    Step 2 connects applicable coding practices, specific error checks and component maintenance with the version. Technical practices and effective code reviews must be applied in the development tools.

  • A.8.29 · Sicherheitstests in Entwicklung und Abnahme (DE)

    Supporting contribution

    Step 4 connects requirements-based tests, results, retests and independent acceptance for in-house development. Actual test cases and results must be carried out and retained.

  • A.8.30 · Ausgelagerte Entwicklung (DE)

    Supporting contribution

    Steps 1 and 4 connect outsourced development with agreed requirements, deliverables, usage rights and review of the actual delivery. Ongoing supplier management is reused.

  • A.8.31 · Trennung von Entwicklungs-, Test- und Produktionsumgebungen (DE)

    Supporting contribution

    Step 3 and controlled implementation in step 5 connect risk-based environment boundaries, access and actual checks for unauthorised transitions. They do not automatically establish technical separation.

  • A.8.32 · Änderungsmanagement (DE)

    Supporting contribution

    The workflow connects impacts, requirements, testing, decisions, controlled implementation, rollback and result checks in the existing change record. Actual execution and follow-up remain necessary.

  • A.8.33 · Testinformationen (DE)

    Supporting contribution

    Step 3 and completion in step 6 connect suitable test information, separate authorisation for operational copies, protection, traceable use and secure removal. They do not automatically meet legal requirements.

Further framework mappings of this measure

  • TISAX · 5.2.1

    VDA ISA 6.0.3 · Partial contribution

    The specific change record supports security requirements, impact assessment, approval, testing, rollback and result checks. Actual execution and applicable additional requirements remain necessary.

    Read the source ↗

  • TISAX · 5.2.2

    VDA ISA 6.0.3 · Partial contribution

    Step 3 connects risk-based separation and protection of development, test and production environments. The actual risk assessment, segmentation and technical implementation still need to be evidenced.

    Read the source ↗