Software development begins with an idea of creating a product that will help to simplify or improve the quality of a process or task. There are functional requirements to how the software should solve the task.

Background

Software development should follow a methodology with key activities to ensure that the final product is robust. There is some technical literature that focuses on security by design as part of developing software. However, there is less about data protection by design and by default as part of developing software. While working on this guide, we have used Microsoft Security Development Lifecycle (SDL),  Secure Software Development LifeCycle (S-SDLC) and ENISA; Privacy and Data Protection by Design – from policy to engineering, as a starting point, and explored how to incorporate data protection principles, subject rights, and the requirements of the GDPR into every step of the process.

Seven activities in a continuous process

The circular diagram at the start of this guide contains the seven key activities in the process of developing software with data protection by design and by default. Each activity is depicted as a jigsaw piece or a step leading to the next activity in the circle. We chose a circle to illustrate because both software development and data protection are continuous processes.

This guide describes each activity in the process, alongside our recommendations on how to carry it out, and what measures we consider important to successfully comply with the requirement to build data protection by design and by default into software. However, this does not mean that each organisation must follow this process to the letter when building data protection into software. It is up to each organisation to decide which methodology to use, which measures, areas, and activities should be emphasised, and where to increase your efforts. The choice of methodology is typically influenced by the services provided, the industry, the type of software being developed, and considerations/perceptions relating to the organisation’s own level of risk.

This guide should not dictate a strict, sequential, and rigid process for each activity in the development process. It should rather be adapted into the specific methodology the organisation has chosen to use. Organisations that develop and release software at a fast pace, should consider how the guide best can be used to ensure that basic data protection and security parameters are in place, and how, for example, data protection and security tests can be included in fully automated testing regimes.

Summary of the activities

The seven activities in this guide start with training. In the section on training, we cover the most important topics on which to provide training, why, how to do this, and which tools to use.

The section on requirements describe the measures needed to ensure data protection and security, the tolerance levels the organisation should set for data protection and security, and the need to assess both security risks and data protection implications.

The next section takes these requirements further, to design, by dividing them into data oriented and process oriented design requirements. During this activity, it is important that the organisation carries out both threat modelling and an analysis of the attack surfaces.

The coding activity underlines the importance of developers using approved tools and frameworks, disabling unsafe functions and modules, and regularly carrying out static code analysis and code review.

The section on testing involves a recommendation to test whether data protection and security requirements are implemented properly, a description of what sort of security testing should be carried out, and an explanation of the importance of threat modelling and analysing the attack surface.

Before release, an incident response plan should be established, and a full security review of the software should be carried out. Release is then approved and all relevant data from the entire development process are archived.

The final activity involves the maintenance of the software and the response to incidents. The organisation should be prepared to respond to incidents, personal data breaches, faults and attacks, and be capable of issuing updates, guidelines, and information to users and those affected by the software.

Data protection legislation contains basic principles for safeguarding the privacy of data subjects. Data protection by design and by default helps ensure that the information systems we use fulfil these data protection principles, and that the systems safeguard the rights of data subjects.

Data protection by design, and data protection by default, are central requirements in the General Data Protection Regulation (GDPR) that apply from May 2018. This guide describes how to comply with these requirements. The data controller must comply with the requirements governing data protection by design during software development, and when ordering systems, solutions, and services. The requirements must accordingly also be included when entering into agreements with suppliers, and when using consultants.

Transparency is a principle in the new regulation, and it is crucial when building data protection into software. Transparency about the use of personal data involves providing information about what is being processed, by whom, why, how, and for how long it is kept. In order for data subjects to exercise their rights, organisations must be open about their processing of personal data. That way, the data subjects can make informed decisions about whether or not to use a software, and this ensures the legitimacy and effectiveness of the data controller.

Management commitment is crucial for making the decision to apply the principles of use data protection by design in the organisation’s procurements and software development. Management must also ensure to provide sufficient resources for this task. Taking data protection into account throughout the development process is both cost-effective and more efficient than making changes to an existing piece of software. Enterprises that do not comply with the GDPR risk significant costs, in the form of both fines for breaking the law, liability to the data subjects, and loss of revenue resulting from damage to their reputations.

The target group for this activity is management and employees in the organisation.

What is important to learn

An understanding of data protection and information security is a prerequisite for developing software with data protection by design and by default. Employees should know what requirements are applicable, what they should look out for, and which tools enables them to convert knowledge of data protection and information security into software that safeguards it.

Employees must also know which methodology and routines should be followed. The organisation itself must decide what is relevant, and what type of training is required for individual employees. A training plan should be drawn up.

Which requirements apply for the organisation?

The employees should receive training in the relevant internal and external requirements. Internal requirements may relate to data protection, information security, internal control, and resource management. This includes routines for risk assessment and requirements for documentation. External requirements include data protection law in general, the significance of the data protection principles in particular, and rights of the data subjects.

Other external requirements might include regulatory and mandatory requirements related to the subject area, sector, or industry for which the software is to be developed. There may also be a requirement to follow best practices, standards, code of conducts for the chosen technology. Examples of these include the Freedom of Information Act, the Patient Records Act, the pending ePrivacy Regulation, the Regulations on the Use of Information and Communications Technology (ICT), the framework for information security (for example ISO27001, and the ISF Standard of Good Practice for Information Security (SoGP).

How to do this in practice Software developers should have an established development methodology, approved by management, that they follow when developing software. When developing software that processes personal data, the methodology should include data protection by design and by default, and security by design. Examples of development frameworks with embedded security are Microsoft Security Development Lifecycle (SDL) and OWASP Flagship projects.

Which tools can be used? The organisation should prepare an overview of the tools, standards, and best practices that should be used during software development. Employees should be trained in which tools they can use, how to use them, and for what purposes. Examples of tools for tasks including security testing, setting security requirements, measurement, and threat modelling can be found in:

OWASP Application Security Verification Standard Project (OWASP ASVS)

OWASP Top 10

OWASP Testing Project

ISO27k information security

Microsoft SDL

Download

Example of a checklist for what training activities should include (pdf)

The target group comprises everyone involved in development, or with ownership of the software, including those responsible for defining the requirements, the product owners, customers/purchasers, project leaders, developers, architects, and testers. The Data Protection Officer and security advisor should also be involved in this activity.

When requirements for data protection and security, tolerance levels, data protection impacts, and security risks are detected early, the development team will already know which requirements they need to meet, and can therefore mitigate the risks associated with data protection and information security throughout the development process.

Requirements for data protection and information security

To set the correct requirements, it is important to know what categories of personal data will be processed in the software, what conclusions can be drawn about individuals based on the data being processed, who is the user and owner of the data, who is defined as the controller, and if applicable, who is the data processor or recipient of the personal data. This is necessary for determining which laws, rules, guidelines, and codes of conduct are applicable to the software being developed. These provide guidelines for determining which requirements should be set for the software.

Relevant requirements for data protection and security are contained in the data protection regulation, business practices and policies for data protection and information security, various security standards, and codes of conduct or other relevant laws and regulations relating to the sector. The company must decide for itself which requirements are relevant to their business, the software being developed, and the context in which the end product will be used. Requirements for data protection and information security should be formulated in a checklist that should be integrated into the project plan, and monitored throughout the development process.

Meet the data protection principles

The most important requirement applicable to software with data protection by design is that the data protection principles are met. The processing shall be lawful, fair and transparent. Processing of personal data shall be carried out for specified, explicit and legitimate purposes, and only data that is necessary for the software to function shall be collected.

By “necessary”, we mean that you must assess the amount of personal data, extent of their processing, the period of their storage, and their accessibility. For example, you should consider the level of detailed information required, how long the data will need to be stored, whether automatic deletion routines can be implemented, where the data will be stored, and who will have access to the data, and from where.

Concise information and secure the data

Clear and concise information about how the personal data will be used is fundamental to ensure protection of data subject’s rights. The software must make it easy for the data subjects to exercise their rights, such as access, information, rectification, restriction, and data portability. This can, for example, be resolved by using a login portal that provides an overview of the registered data, information on users’ rights, and a help form that can be used to make objections or rectifications.

The company must ensure the security of personal data during e.g. collection, storage, alteration, viewing, communication, and deletion. Encryption and access control are examples of measures that can be used to help ensure security.

The security requirements for the software are determined by identifying which risks the software may be exposed to, and which risks the company is willing to take. This defines the parameters for selecting relevant and correct measures for the company and the software. We recommend using the Data Protection Authority’s checklists and recognised standards for information security when selecting relevant measures. 

Generic examples of suggested measures:

OWASP ASVS

ISO27001

The ISF Standard of Good Practice for Information Security (SoGP)

Defining risk tolerance levels

Risk assessment is about identifying the potential consequences of different incidents or scenarios, and assessing how likely or easy it is that an unwanted incident occurs. It is the company’s management that determines the degree of risk the company is willing to take in different scenarios. This is called risk tolerance. This tolerance level provides guidance on what measures and resources need to be put in place to ensure that the software does not exceed the defined level of acceptable risk.

In terms of security, the tolerance level is defined individually for different “security scenarios”. Examples of such security scenarios could include accidental alteration of personal data, unauthorised disclosure of personal data, and a lack of accessibility that could significantly affect life and health.

In terms of data protection, the tolerance level is defined individually for different “data protection scenarios”. Examples of such data protection scenarios could include the data subject losing control over his/her personal data, the data subject being subjected to discrimination based on profiling carried out by the software, or a person being re-identified from anonymised data.

Some security scenarios and data protection scenarios will have zero tolerance for risk, while for others, the company may be willing to take a certain degree of risk. Management must set acceptable tolerance levels, i.e. risk appetite, for both data protection and security.

The company’s risk appetite may be documented by defining tolerance levels for data protection or security in different scenarios, often in a reference table that can be reused for other risk assessments.

Security Risk Assessment

A risk assessment begins with mapping values that should be secured. The data protection regulation defines personal data as a value.

A threat assessment should be carried out to identify which actors could be interested in the values, and which attack vectors different threat actors use. An evaluation is then carried out to determine which values are vulnerable to any given threat. Information security standards can help to detect vulnerabilities, thus also identifying the requirements that need to be established for data protection and security.

The result of the risk assessment should be assessed against the security tolerance level. If the risk level is higher than the pre-determined level of acceptable risk, measures must be implemented to mitigate the risk. It is also necessary to determine who will be responsible for the measure, and to set a deadline for implementation.

Data protection impact assessment

The purpose of a data protection impact assessment is to assess the impact an envisaged software or processing operation may have on the protection of personal data. It is to ensure that the software does not infringe on the data subject’s fundamental rights. The processing should, for example, be lawful, fair, and transparent. For certain types of processing of personal data it is required to carry out a data protection impact assessment:

1. In the case of a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated decision-making, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person,
2. when processing sensitive personal data on a large scale, or
3. a systematic monitoring of a publicly accessible area on a large scale.

If you are in any doubt, we recommend carrying out a data protection impact assessment. The assessment shall contain at least:

• A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller,
• an assessment of the necessity and proportionality of the processing in relation to the purposes,
• an assessment of the risks to the rights and freedoms of the data subjects, and
• the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the data protection regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.

In cases where a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken to mitigate the risk, the data protection regulation requires that you contact the Data Protection Authority for a prior consultation.

We recommend The Article 29 Data Protection Working Party’s Guidelines on Data Protection Impact Assessment (DPIA)

Download

Example of a checklist for setting requirements (pdf)

It is important to take into account the existence of threat actors that may attempt to obtain and gain access to personal data. To reduce the attack surface, it must be analysed, and the software modelled and designed to ensure a robust end product.

The target group for this activity is primarily architects, secondarily data protection officers, security advisors, and developers.

Design requirements accurately and comprehensively describe how the characteristics of each piece of software should be developed. The requirements need to describe how functionality can be implemented and distributed in a safe and secure manner. An example could be an identity and access management system where the user can see what he or she has consented to, his or her security settings and configurations, password management, and how the login process works. We have split the design requirements into two categories, data oriented and process oriented requirements, as recommended by the European Union Agency for Network and Information Security (ENISA).

Data oriented design requirements

1. Minimise and limit – The amount of personal data collected and processed should be limited to what is lawful and what is strictly necessary. The data shall be deleted when storage is no longer required for the purposes. A good rule of thumb is “Select before you collect”.
2. Hide and protect – Personal data, and their interrelationships, should not be communicated, processed, or stored in plain view. By hiding directly identifiable personal data from plain view, the risk of abuse and the scope of potential incidents is significantly reduced. Examples include pseudonymisation, encryption, and aggregation of personal data.
3. Separate – By separating the processing or storage of several sources of personal data that belong to the same person, the possibility of creating complete profiles of one person is reduced. For example, personal data can, based on their purpose, be stored in separate databases, units, components and areas. Separation is also an effective means to achieve purpose limitation and to avoid linkability between different data sets. A fixed time should be set for automatic deletion in tables containing personal data. This can be done by access control to tables containing personal data, splitting database tables, and distinguishing between components, units and areas with a high level of trust and those with a lower level of trust.
4. Aggregate – In order to safeguard the protection of the data subject’s rights, personal data should be collected and processed with as much aggregation as possible. You should avoid detailed personal data as much as possible, within the limitations of what can still have business value, and what is relevant to the purpose of collection and use. Examples include reducing the detail and sensitivity of personal data concerning individuals, and by removing unnecessary or excessive information whenever possible. To illustrate general trends or values, you can combine statistical data about large numbers of people without identifying individuals.
5. Data protection by default – All settings should, by default, be configured to the most privacy-friendly setting. The user should make a conscious choice to change any setting that would result in a less privacy-friendly configuration. When installing an app, the default configuration should be that the app does not track the user’s location, or share the user’s data with others. If the user wishes to use such features, he or she must actively choose to change the settings.

Process oriented design requirements

1. Inform – The software should be designed and configured so that the data subject is sufficiently informed on how the software works and how personal data is processed. When profiling or automated decision-making of personal data are being conducted the data subject should be informed on how it is being done. It is important to remember that special requirements apply if the software is aimed at children. For example, the software should, using clear and plain language, provide information about what personal data will be used for. Images, icons, and symbols may be used to make the information clearer and more intelligible. Animation, video, and sound may be good tools for customising information to the user’s level of understanding.
2. Control – The data subject has the right to control their own personal data. This includes a right to access, update, and/or delete their own data. Where automated decision-making is taking place, or decisions are being made without human intervention, the data subject can demand manual processing. The software should be designed so that the data subject can exercise these rights as easily as possible. One example might be that the user could use a menu or a separate page within the program to give and withdraw consent, allow to view, block, update, and delete their own personal data.
3. Enforce – The software should be designed so that it may facilitate documenting how it safeguards the data subject’s rights. The documentation should cover accountability and how the data protection regulation is enforced. It should be available for audits and inspections of the processing. This also includes artificial intelligence, profiling, and automated decision-making. One example would be to have a data protection or privacy policy describing how the software ensures the enforceability of the data subject’s rights, how you comply with data protection regulation, and what technical measures are in place to protect personal data. Technical measures might include access control and encryption.
4. Demonstrate – The controller must be able to document compliance with the data protection regulation and security of processing. The software must be designed and developed so that the controller can document and demonstrate how the requirements of the data protection regulation have been implemented. Examples include documentation demonstrating that the software has been developed using a methodology that ensures data protection by design and information security (SSDLC - Secure Software Development Life Cycle), reports from security audits, vulnerability scanning, security tests such as penetration testing, and reports on exercising data breach management.

Reduce opportunities to exploit vulnerabilities

Analyse the attack surface of the designed software to reduce attack vectors and opportunities to exploit weak points and vulnerabilities. In a design review, both communication and data flow, input and output should be analysed through the eyes of an attacker. You should also always investigate whether the same type of information is being collected or stored in multiple locations (duplicated functionality) and assess whether this functionality can be simplified. By keeping the design simple, and eliminating unnecessary features and complexity, the likelihood of errors will be reduced.

In this sort of analysis, you should use the assessments of both security risks and data protection impacts that were completed during the requirement activity. If a vulnerability is revealed, mitigating measures must be implemented to achieve acceptable risk level for data protection and security. The tolerance/risk level should be set in the requirement activity. Analysis and reduction of the attack surface should be documented.

Threat modelling Threat modelling involves the analysis of components, access points, data flow, and process flow within the software. Those involved should analyse how someone could misuse the software in different scenarios. You should review each scenario to see how the design can be improved to avoid any threats that are identified. This is done by implementing vulnerability-reducing measures, resulting in a more robust end product.

As a follow-up, you should carry out a risk assessment of any vulnerabilities that remain, and which must be mitigated using other measures. These vulnerabilities should be entered into a risk log.

Download

Example of a checklist for content in the design activity (pdf)

It is important that the company choose a secure and common methodology, both for coding and for enabling the developers to detect and remove vulnerabilities from the code. Automated code analysis tools should be introduced, and the company must have established procedures for static code analysis and code review.

The target group for this activity is primarily developers, secondarily data protection officers, security advisors, and testers.

Use approved tools and frameworks

To ensure consistent practice, a list of approved and permitted tools, processes, and frameworks for software development and roll-out must be defined and documented. In addition, it must be clear what the different tools may be used for. This entails describing approved tools and associated security features that can help to automate and enforce security procedures in the coding. The list should also include which supporting components, and third-party components and development tools, are permitted for use during development. Tools and supporting components should be risk-assessed and analysed for vulnerabilities. The list should be agreed upon and approved by the security advisor, and must be updated regularly. It should be a goal to use the latest versions of approved tools to take advantage of the opportunities provided by new security features. For example, the list may include the approved encryption technology and cryptographic key length. The list should be updated regularly with the most recognized and up-to-date algorithms and methods, and what key length is deemed sufficient.

Software today is often composed of several collaborating services. This means that a significantly greater number of programming languages, libraries, and frameworks are used in software development now than in the past. Code, libraries, and infrastructure are often merged into more static containers. This is why it is so important for regular scanning for vulnerabilities to be set up in all parts of the code, both in the underlying libraries and in the container setup. Examples of such tools can be found on GitHub and Docker Security Scanning.

Disable unsafe functions and modules

Many functions, APIs, third-party libraries and modules can be unsafe to use based on current threat levels. An analysis should be performed on all functions, APIs, third-party libraries and modules used during software development. Those that are unsafe should be forbidden, while those that are outdated, or contain known vulnerabilities, should be updated. When a blacklist is available, the code should be checked (including inherited code) to replace blacklisted features with safer alternatives. This can be done using code scanning tools. In addition, the code should be checked to deactivate unnecessary tracking, logging, and collection of personal data. For example, unsafe functions and modules can in some cases be handled by tools such as OWASP Dependency Check.

Static code analysis and code review

Static code analysis and code review should be performed on a regular basis. Static code analysis ensures that guidelines for secure coding are being followed and can be measured to ensure controls are working. You should use automated code analysis and code review tools as much as possible. Additionally, the code should be manually reviewed to ensure that any weaknesses that could lead to improper use or leakage of personal data are caught. For example, it may be difficult to identify patterns because data alone does not necessarily constitute personal data, but connections between different types of data can provide personal information. In order to ensure data protection, it is important to map where in the software personal data is stored. A review of the code should particularly examine where personal data is written. A common weakness is to write personal data in application logs with insufficient security.

Download

Example of a checklist for content in the coding activity (pdf)

The software must also be tested for vulnerabilities. This is done using dynamic testing, fuzz testing, and penetration testing. It is important to review the attack surface to verify that attack vectors uncovered during the Design activity, and potential new attack vectors introduced during coding, are handled.

The target audience for this activity is primarily testers. Data protection officers and security advisors, developers, and project leaders may also be involved in testing.

Test that requirements for data protection and security have been implemented

Tests should be carried out to ensure that requirements for data protection and security are met through design and coding, and that the requirements have been correctly implemented within the software. The checklist prepared during the Requirements activity should be used to verify that all components required to meet the requirements are included in the software. The verification should, where applicable, include new components introduced later in the development process, during design and coding. For testing, synthetic personal data should be used.

Security testing

Security testing involves comprehensive testing of the software to discover vulnerabilities and to ensure that the code adequately safeguards security and data protection. We recommend establishing procedures for automatic execution of test sets, which should be run each time software is built.

Dynamic testing

Test functionality in running code by using tools or manual reviews to analyse how the software behaves in relation to different user permissions and in the cases of critical security failures. The testing will ensure that users only have access to the information and functionality that they are authorised for. It is important to verify that attempts to gain unauthorised information are logged as security breaches. Examples of known vulnerabilities that should be investigated while running the software are Cross-site scripting and SQL injection. Session management, cookie use, and access control should also be tested to ensure that personal data cannot be retrieved by users who are not logged in.

Fuzz testing

This sort of testing is conducted by intentionally triggering errors in the software. This can be done using tools that send random and malformed data (incorrect input values) to all possible input fields in the software, either manually or using intelligent tools that analyse vulnerabilities in web applications. If the software has multiple interfaces, efforts should be made to test each of them. Use tools that can analyse output and apply security contexts, such as web proxies with the capacity to scan for vulnerabilities in their own software.

Penetration testing/vulnerability analysis

In order to detect vulnerabilities, penetration testing or vulnerability analysis should be carried out before release, and at regular intervals. Such a security test must be a legal and authorised attempt to find, exploit, and detect vulnerabilities. Following the test, measures to make the software more robust should be implemented. Because knowledge can be personnel-dependent, you should regularly rotate those responsible for testing. Furthermore, it is advisable to use security advisors to analyse the results.

Threat model and attack surface review

As software can differ from the functional and technical specifications defined during the Requirement and Design activities, both the threat model and the attack surface should be reviewed once the software is complete for release. This review should verify that new attack vectors that may have been introduced during coding have been identified and managed, and that the threat model is being reviewed against newly developed software. As the requirements may have changed during the development process, data protection impacts must be reviewed again. For example, verify that all personal data has a legal basis for processing, is necessary and is adequately protected.

Download

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

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)

The organisation must be prepared to handle incidents, security breaches, and attacks that can result in breaches of confidentiality, integrity, or availability relating to personal data. It should have a response centre that can handle incidents and deliver updates, guidelines, and information to users and data subjects.

The target group for this activity is primarily the response incident team, security advisors, and data protection officers, as well as maintenance, service, and operation staff.

Handling incidents and data breaches

The organisation should operate an incident response plan. When critical incidents occur, it is important to remain calm and analyse the incident in a comprehensive manner. Note that the nature of the incident may result in changes to how the plan is being executed. The response incident team should know whom to contact when necessary, and who is responsible for building, testing, and installing updates. The response incident team should also know which priorities apply, as well as exactly what they can and should do in the event of a crisis. In order to achieve this, staff requires periodic incident response training. For more information on how to do incident response training, see the Agency for Public Management and eGovernment’s (Difi) guidelines for planning and conducting ICT drills.

Incidents should be reported to a defined point of contact or response incident centre that handles internal and external incidents. Incidents should be reported via the defined channels described in the incident response plan developed during the release activity. Users of the software should be encouraged to report errors, vulnerabilities, and data breaches, so that the software can be continually improved and further developed. Incident assessments should also follow this plan.

Maintenance, service and operation of the software

Follow the organisation’s procedures for maintenance, service and operation of the software. This includes procedures for a continuous safeguarding of data protection and security. Examples of such procedures are regular security testing, vulnerability analysis, and penetration testing of software, infrastructure and network. The procedures should include error debugging, performance improvements, updates, and patching, of both the software and third-party components. It is important to define what can and what should be logged. The company must also have the capability to regularly secure, monitor, and handle incidents in the logs. Note that personal data being logged one place is often exported to other applications and may become available to more people than those who are authorised (privilege escalation).

Conduct regular external and internal audits to document compliance with relevant regulations.

The company should have a management system for data protection and information security that includes procurement, maintenance, service and operation. The management system should be established in accordance with recognised frameworks, such as:

ISO 27001 

The ISF Standard of Good Practice of Information Security (SoGP)

Download

Example of a checklist for setting requirements to the maintenance activity (pdf)