Review and safely implement a system change

What to do

1. 1

   Define requirements and secure design

   Open the existing record and describe the purpose, affected systems, information and dependencies. Derive security requirements and testable criteria, and have the authoritative version confirmed. Use data flows and interfaces to identify where access, input and errors are handled. Apply relevant principles such as least privilege and secure defaults. Check how safeguards work together and which deviations need a decision. For outsourced development, agree suitable rules, deliverables, usage rights and evidence through the existing supplier process.

2. 2

   Control code, development access and components

   Use the defined secure practices for your languages and tools. Check relevant errors, such as missing server-side authorisation, unsafe database calls or secrets in code. Track component versions from trusted sources and address known vulnerabilities. Grant read and write access to code, libraries and development tools separately by task, including technical identities. Approve rights and changes through the authoritative access process, implement them in the target system and check their effect. Keep traceable logs of access and code changes there.

3. 3

   Prepare environments and test information

   Set up risk-based boundaries between development, testing and production, with controlled implementation paths. Use suitable roles to check whether unauthorised access or changes are possible. Protect development tools and test environments too. Prefer artificial data that suits the test. Authorise each necessary operational copy separately, restrict access, remove or mask sensitive content where possible and keep copying and use traceable. Plan secure removal after testing.

4. 4

   Test security and accept the specific version

   Test expected and unauthorised cases against confirmed requirements under suitable target conditions. Select manual or automated methods according to technology and impact. Also check appropriate configuration and components. Keep the version, results, errors and retests in the existing record. In-house development needs independent acceptance in addition to developer testing. Check outsourced deliverables against the agreed criteria and resolve remaining deviations before the authorised role decides. A green scan report or supplier certificate does not replace that decision.

5. 5

   Implement the approved version in a controlled way

   Plan the timing, authorised competent administrator and a workable rollback or alternative route. Check the source, integrity and maintenance status of the intended release. Implement only the tested, authorised version with the required rights. Keep traceable logs of the installed version, configuration and updates. Retain necessary old versions with settings and dependencies for rollback and processing retained data. Give external installers only necessary approved access and monitor their work. Urgent changes remain authorised and controlled; skipped work is completed afterwards.

6. 6

   Check the result and continue maintenance

   After implementation, check affected functions and safeguards. Use the prepared rollback route if consequences are unacceptable. Update operating and necessary recovery documentation. Remove unneeded access and operational test copies under the authoritative rules, and record completion. Follow through remaining corrections against the affected version. Later, review new vulnerabilities, component and technology changes, and introduce necessary adjustments through the same development and change process.

Worked example

Example: An application gains a data export

A team adds an export to an existing service. The current development record connects requirements, code review, testing and implementation.

Record the result

• The existing record connects confirmed requirements and design decisions with the code or delivered version actually tested.
• Access, environments and test information are appropriately protected. Technical identities and external access are considered alongside personal permissions.
• Tests, corrected errors, retests and appropriate acceptance refer to the specific version. Outstanding deviations have been decided.
• Actual implementation, result checks and necessary rollback are traceable. Operating documentation, test copies, access and later maintenance are followed through.

Reuse the implementation across requirements

The references below show which requirements the measure contributes to.

Templates for your implementation

• 

  Template

  Joint change and development policy

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

  Free ZIP · DOCX, ODT and PDF · editing instructions included

  Request template
• 

  Template

  Use the existing access control concept

  Adapt identity management, approvals and access reviews to your organisation. If you already maintain a suitable role model, link to it from the concept.

  Free ZIP · DOCX, ODT, PDF and XLSX · with editing instructions

  Request template
• 

  Template

  Reuse information protection and deletion rules

  One policy for information classes, labelling and handling. With fields and an example classification scheme to adapt to your organisation.

  Free ZIP · DOCX, ODT and PDF · with editing instructions

  Request template