Release

In organisations where software releases are frequent, an incident response plan should be established before the initial release, while security reviews should be carried out upon each release. It is important to archive all relevant data from the development process.

The target group for this activity is primarily project leaders, security advisors, and data protection officers. When preparing an incident response plan, those responsible for incident response handling should contribute, while testers should contribute to the security review.

Incident response plan

The organisation should establish a plan for managing incidents relating to the software. The plan should contain defined resources and a contact point or response centre that can manage incidents. The plan should contain relevant contact information for support and escalation, including contact information for the organisation’s Data Protection Officer. The plan should also contain an overview of how incidents in code inherited from third-parties should be managed. The response time should be defined based on the importance of the software. For example, software related to emergency care in the health sector will probably require that a 24-hour response centre be available 365 days a year. It is important to consider which communication channels should be used to report incidents. For example, do the channels adequately safeguard the security of the contents of messages, and the privacy of those making the reports?

The plan should define what comprises an incident and its life cycle. One example could be detection, analysis, reporting, handling, and normalising. Furthermore, the plan should describe the configuration and handling of logs, including guidelines imposed by the data protection regulation. The plan should also contain procedures for evaluating incident response (“lessons learned”). It should also briefly describe what consequences these experiences may have for the development process, the business, and those affected.

If the incident includes a breach of confidentiality, integrity, or availability relating to personal data, the controller must be able to notify the Data Protection Authority within 72 hours, and the data subjects should be notified immediately if it likely to result in high risk to the rights and freedoms of the natural person.

The plan should contain a regime for patching the software that includes policy and follow-up. This also applies to third-party code. The plan should be updated regularly, and the company should define which triggers require updating.

Full security review of the software

The review should be based on previous reviews during the development process, and be included in the control gates that must be carried out prior to release. All requirements, analyses, and assessments carried out during the development process must be reviewed again, to uncover any deviations. Different groups of experts should be involved in each security review, to ensure the best possible review of different scenarios and consequences, as well as the best possible quality of any measures implemented as a result.

Release approval Data Protection Officer and the security advisor should verify that all the data protection and security requirements have been implemented and are functioning as intended. The organisation must define who is authorised to make the final approval to release the software.

All relevant data and documentation from the entire development process should be archived. This is important for performing support tasks, and will help to reduce long-term costs related to software management and maintenance. Archiving is also important for customers and supervisory authorities.

Download

Example of a checklist for content during the release activity (pdf)