Consultation outcome

Government response to the call for views on app security and privacy interventions

Updated 9 December 2022

1. Executive summary

The UK government is the first country to make the case for baseline security and privacy requirements for application (“app”) developers and app store operators via a voluntary Code of Practice. We previously published an extensive evidence base alongside a Call for Views on the Government’s App Security and Privacy proposals which highlighted the need for intervention to protect users. The Call for Views was held from 4 May to 29 June 2022 and sought feedback on the scope of the Government’s review into app privacy and security, perceived issues in the app ecosystem and potential interventions.

The government received 59 responses to the Call for Views. The vast majority of respondents supported all principles within the voluntary Code of Practice and the need for the Code. There was broad support for commencing work to explore how the Code could be put on a regulatory footing in the future. We have taken on board respondents feedback to produce the updated Code and determine our next steps.

The government strongly believes that the updated Code of Practice will help protect users from malicious and poorly developed apps. We commissioned a mapping of the app standards landscape which found that there are no security standards or recommendations for all app store operators and no universal standard for app security.^{[footnote 1]} The Code will therefore provide clarity and improve the security and privacy practices of app store operators and app developers.

Given the global nature of cyber security issues, and digital markets, we also recognise that this work should be taken forward in collaboration with international partners. Therefore, we will be examining the viability of international standards and will be looking to create an international coalition around the Code’s baseline security and privacy requirements.

This document provides an overview of the key feedback raised by stakeholders. We have provided responses to each question set out in the Call for Views in order to explain how feedback and concerns have been taken on board in updating the Code of Practice and in determining the government’s next steps in this space.

2. Background

Apps are one of the most important pieces of technology. Their ability to provide users with essential services across a range of devices has helped create a vibrant industry and enhance our day-to-day lives. The app development industry in the UK is expected to generate at least £21.8 billion of revenue in 2023.^{[footnote 2]} Moreover, in January 2022, it was reported that global mobile app downloads for 2021 were a staggering 230 billion.^{[footnote 3]} This precedes 218 billion downloads in 2020.^{[footnote 4]} This only provides a glimpse into the usage of apps as thousands of apps are also available for desktops, smart TVs, gaming devices, voice assistants and wearable devices.

For many users, their most likely method for accessing apps is via app stores. If users download malicious or poorly developed apps, this could result in them losing significant amounts of personal data and money as well as access to their devices. This means that both app store operators and app developers share responsibility for the experience and protections that are put in place for app users.

The UK government’s review into the app ecosystem found that there are clear security and privacy concerns facing users. A Call for Views on the government’s app security and privacy interventions was held from 4 May to 29 June 2022. The proposals, which included a voluntary Code of Practice, centred around improving the security and privacy practices of app developers and app store operators whilst increasing the information available to users to allow for more informed decisions to be made.

The report, and the continuing activity which it sets in motion, is part of a broader programme of work under the UK’s National Cyber Strategy. It also complements ongoing work across government to help create a vibrant pro-competition regime whilst also ensuring that our overall approach to governing digital technologies is proportionate and supports growth and innovation within the sector.

3. Overview of regulatory ecosystem

This work is complemented by other UK legislation. The Code has been designed to fill regulatory gaps and also complements existing legislation. This section provides an overview of some of the relevant laws that interlink with the app ecosystem to further inform app store operators and app developers.

3.1 Data protection law

UK data protection law, the UK General Data Protection Regulation (UK GDPR) and Data Protection Act 2018 (DPA18), sets out responsibilities for different stakeholders. Under these laws, the obligations for a particular entity will vary depending on whether they are a controller, joint controller or processor. In the Code of Practice, we have collaborated with the Information Commissioner’s Office (“ICO”) to extensively map the relevant articles of data protection law and the legal requirements placed on developers and app store operators in the app ecosystem.^{[footnote 5]} The ICO has the power under UK GDPR and DPA18 to conduct investigations to identify where relevant stakeholders are non-compliant with data protection law. In the event of a data breach, the ICO may investigate in order to understand how the data was accessed and the extent to which data protection requirements were in place. For the most serious offences, the ICO has the power to fine stakeholders up to £17.5 million or 4% of total annual turnover, whichever is higher.

3.2 Network and Information Systems Regulations

The ICO is also the competent authority for Relevant Digital Service Providers (RDSPs) under Network and Information Systems (NIS) Regulations 2018. As the competent authority, the ICO has a range of powers to aid enforcement of the Regulations including issuing fines of up to £17 million in the most serious cases. RDSPs are organisations providing online marketplaces, online search engines, and cloud services. In the future, this may include other digital services, such as managed services.^{[footnote 6]} App stores are a type of online marketplace and therefore have obligations under the NIS Regulations. The only exception to this is if an online app store is subject to the small and micro enterprise exemption.

The NIS Regulations are intended to establish a common level of security for network and information systems. These systems play a vital role in the economy and wider society. The NIS Regulations aim to address the threats posed to them from a range of areas, most notably from cyber attacks. Although the Regulations primarily concern cyber security measures, they also cover physical and environmental factors. NIS Regulations require these systems to have sufficient security to prevent any action that compromises either the data they store, or any related services they provide. They also require RDSPs to report relevant incidents to the ICO.^{[footnote 7]}

3.3 The Product Security and Telecommunications Infrastructure (PSTI) Bill

Once the Bill reaches its anticipated Royal Assent, Part 1 of the Bill will give the government the necessary powers to set minimum security requirements for consumer connectable products. These requirements will initially be based on the top three guidelines of the Code of Practice for Consumer IoT Security and similar provisions in ETSI EN 303 645. The Bill creates obligations on relevant persons in the supply chain to comply with these security requirements, and establishes an enforcement regime to oversee compliance with these obligations.

3.4 Consumer law

There are several pieces of relevant consumer legislation, the most important of which are: i) The Consumer Rights Act 2015; ii) The Consumer Protection from Unfair Trading Regulations 2008; and iii) The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, all summarised below. Consumer law stipulates the provision of accurate information to consumers as well as several substantive fairness provisions not limited to transparency. As consumer law is principle-based it generally looks at the impact on consumer decision making of potentially problematic practices rather than setting out simple rules – this means traders need to consider the effect of their practices and terms on end users.

3.5 The Consumer Rights Act

Part 1 of the Act sets out consumer rights in relation to goods, services and digital content, setting out expected standards and the rights and remedies where these standards (as described, fit for purpose etc) are not met. Part 2 sets rules on unfair contract terms, which include end user licence agreements and terms as part of digital contracts between traders, consumers and third parties – terms have to be both meaningfully transparent and substantively not unfair. The Act sets out an indicative, non exhaustive list of terms which may be regarded as unfair. It also sets out how unfairness is to be assessed. Certain exclusions apply, for example, the unfairness assessment  does not apply to terms which (a) specify the main subject matter of the contract, or (b) concern the appropriateness of the price payable under the contract by comparison with the goods, digital content or services supplied under it.

Additionally, Part 2 only applies to contracts between traders and consumers and certain contracts e.g. contracts of apprenticeship or employment are excluded. Consumers are not bound by unfair terms (as defined in the act). Consumers are not bound by unfair terms, which include unbalanced terms around limitation of liability, unilateral variation, cancellation, termination and other matters. More information can be found in guidance Unfair contract terms: CMA37.

3.6 The Consumer Protection from Unfair Trading Regulations (CPRs)

The CPRs set out principles on commercial practices that affect consumers’ transactional decisions. One particularly relevant category of commercial practice is around misleading actions, like false or deceptive advertising or communications. In the case of apps and app stores, this means that providing false information could break the law. Traders can also mislead by omitting to provide material information, which is likely to include information on privacy or data sharing, in a clear and timely manner i.e. prior to purchase. Aggressive commercial practices as defined in the CPRs are also prohibited. Misleading actions, misleading omissions and aggressive practices as defined in the act are unfair (and subject to the related penalties) where they cause or are likely to cause the average consumer to take a transactional decision they would not otherwise have done. 31 practices are banned and automatically considered unfair (without the need to establish it causes or is likely to cause the average consumer to take a transactional decision they would not otherwise have done) in all circumstances.

Additionally, under the CPRs, a commercial practice is unfair if it fails to meet the requirements of professional diligence and is likely to materially distort the economic behaviour of the average consumer. More information can be found in guidance Consumer Protection from Unfair Trading Regulations - traders: OFT1008.

3.7 The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations (CCRs)

These Regulations set out detailed provisions about what information, including around charges, needs to be provided upfront to consumers. They also stipulate specific cancellation rights (usually 14 days when not bought in a physical store) and remedies where these cancellation rights are not explicitly offered to consumers. More information can be found in guidance: Consumer contracts (information, cancellation and additional charges) regulations implementing guidance.

3.8 Digital Markets, Competition and Consumer Bill

The Digital Markets, Competition and Consumer Bill was announced as part of the Queen’s Speech 2022. This legislation will set out a new pro-competition regime for digital markets during the current parliamentary session. A Digital Markets Unit (DMU) within the Competition and Markets Authority (CMA) will oversee the regime. Its core objective will be to promote competition in digital markets for the benefit of consumers.^{[footnote 8]} The regime will be targeted at a small number of firms with substantial and entrenched market power, which gives them a strategic position (‘Strategic Market Status’) in one or more activities. Once a firm is designated with Strategic Market Status, the DMU will set out how it is expected to behave through conduct requirements. In addition, the DMU will be able to make targeted pro-competitive interventions, such as those to support interoperability, which have the potential to fundamentally transform digital markets.

In the case of app store operators, the CMA conducted a market study into mobile ecosystems (covering devices, operating systems, browsers, apps and app stores). The final report was published on 10 June 2022. Following findings of competition harms, the CMA consulted on whether to launch a market investigation into mobile browsers and cloud gaming and subsequently launched an investigation on 22 November 2022. The mobile ecosystems report also noted competition concerns in other areas, such as app distribution but stated that at this stage, they considered these issues, and potential interventions, would be better suited to the tailored powers of the new digital regime.

3.9 Medical device laws

Any entity that is considering creating a health-related app should refer to the Medicines and Healthcare products Regulatory Agency guidance Medical devices: software applications (apps) and determine if their app qualifies as a medical device. Medical devices must comply with the UK Medical Device Regulation for Great Britain and with Regulation (EU) 2017/745 for Northern Ireland. The MHRA is responsible for enforcing these regulations for Great Britain and Northern Ireland.

All developers of health apps and digital health technologies should also ensure that they comply with the standards contained in NHS England’s Digital Technology Assessment Criteria (DTAC).

3.10 Online Safety Bill

Under the Online Safety Bill, services which enable users to share content and interact with one another, including apps, will need to put in place systems and processes that improve user safety on their services. This includes removing and limiting the spread of illegal content and protecting children from harmful and age-inappropriate content.

The Online Safety Bill delivers the government’s manifesto commitment to make the UK the safest place in the world to be online. The Bill is a vital piece of legislation, designed to ensure that tech companies take more responsibility for the safety of their users, particularly children. To further protect children, we are also requiring platforms to clearly articulate in their terms of service what they are doing to enforce age requirements on their sites, such as the use of age verification technology. Furthermore, Ofcom will need to consult the Children’s Commissioner when developing its codes of practice to ensure children are represented.

The Bill will defend freedom of expression and the invaluable role of a free press, and will also update the criminal law on communications offences, bringing in new offences of cyberflashing, intimate image abuse, encouragement of self-harm, false communications and threatening communications. The government intends to remove the existing “legal but harmful” measures, which could have inadvertently stifled free speech, and replace them with new duties which strengthen the requirements for major platforms to adhere to their terms and conditions about content moderation. Services will also be required to give adult users greater control over their online experience. Platforms will need to give users who would like to minimise their engagement with particular categories of content tools to reduce the likelihood that they will see that content.

Platforms that fail to protect the public will need to answer to the regulator. Ofcom will have the power to fine companies failing in their duty of care up to 10% of annual global turnover. Many app store providers will not be in scope of the Online Safety Bill. Only providers of services which enable users to share regulated user-generated content (which does not include comments or reviews) or which allow users to search multiple websites or databases will be subject to the Bill’s duties.

3.11 Summary

Whilst the Code remains voluntary, we do not expect regulators to monitor uptake of the Code beyond their responsibilities already set out in law. DCMS will be responsible for commissioning research and working with stakeholders to assess adherence with the Code, particularly among app store operators. Any assistance that can be offered from regulators would be welcome in light of the cross-cutting nature of the principles.

4. Updates to cross-government activity

In the Call for Views, we set out various cross-government work that interlinks with the app ecosystem. Since that publication, there has been some notable new activity that will help protect users and create a more innovative UK economy.

Building on the PSTI Bill, which introduces security requirements for consumer Internet of Things (IoT) products, policy work is underway in DCMS to understand the vulnerabilities that exist in enterprise IoT products. DCMS is also taking a leading role internationally through standards and engaging with other governments to promote the security requirements in European Standard 303 645.

As set out in the National Data Strategy, the government is undertaking work to ensure that data, and its supporting infrastructure, is secure and resilient from established and new and emerging risks, protecting the economy as it grows. As part of this, we are developing a stronger risk management framework to address the risks to UK data storage and processing infrastructure. To that end, we have recently closed a Call for Views on the security and resilience of this infrastructure.

The government introduced the Data Protection and Digital Information Bill in July. It adapts the UK GDPR to create a new bespoke British data protection framework that is business and consumer friendly, and keeps people’s personal data secure. The second reading of the Bill was postponed to allow new ministers to consider the legislation. We will continue to engage with businesses and civil society to ensure the regime works for all. We have ensured that the updated Code of Practice aligns with the proposed changes to UK data protection law. The Code and its annexes will be updated, where necessary, if there are any changes to the legislation.

The government has recently run a Call for Information which seeks views on potential measures to reduce unauthorised access to citizens’ online accounts and personal data, under the working title, ‘Cyber Duty to Protect’. This programme aims to reduce at scale the threat of cybercrime and the offences it often facilitates, such as fraud and domestic abuse, and in line with the National Cyber Strategy, reduce the burden on citizens for cyber security. The programme recognises that any proposals should complement existing obligations and the wider landscape of cyber resilience including the Code of Practice for App Store Operators and App Developers.

The government published a paper which set out a roadmap from 2022 to 2025 to enhance the government’s digital and data services. Part of this document notes that as part of efforts to increase access to government services, a mobile app strategy will be created.^{[footnote 9]} Alongside this, we are taking steps to ensure that government apps will adhere to the requirements in the Code of Practice.

The government is also continuing work on many other interlinking areas, such as the new pro-competition regime for digital markets, fraud and online safety.

5. Methodology

On the 4th of May 2022, the ‘Call for Views on App Security and Privacy Interventions’ was published on gov.uk for a period of eight weeks. Feedback was open to the public and stakeholders were able to respond via an online survey, written mail or via email. 23 (39%) responses were received via email and 36 (61%) responses were received through the online survey. Email and online-survey responses were analysed using the same methodology. The Call for Views included responses from individuals, organisations and public entities. In total, 128 responses were received between 4th May and 29th June 2022. After removing blank and duplicate responses, 59 responses were recorded for this Call for Views. This included 24 (41%) responses from individuals and 35 (59%) responses from organisations.

The Call for Views asked respondents 22 questions, including a mix of both open and closed questions. Respondents were not required to answer any specific questions. For some questions, respondents were offered the opportunity to expand on answers and provide more detail with qualitative open text boxes. These open text boxes were not mandatory. For open response questions, every response was reviewed and responses were coded to identify common themes.

Alongside the Call for Views survey, DCMS participated in a few workshops to allow for more in-depth discussions and to collect verbal feedback from a range of relevant stakeholders. Input collected from these workshops has been analysed to help identify and reinforce key themes that arose from written responses and we have incorporated important feedback to inform our policy development. This government response provides an overview of the findings we have collated through the analysis of the Call for Views responses.

6. Overview of responses

There were 59 responses to the Call for Views over the eight week period. Respondents included app store operators, industry bodies, cyber security companies, academics, developers, foreign governments, regulators and consumer groups. The Call for Views survey consisted of a total of 22 questions. 15 of those questions were concerned with the scope and specific principles laid out in the proposed voluntary Code of Practice, while seven questions were on demographic background. Some percentages displayed below may not add up to 100%, this is due to the rounding of proportions.

7. Section 1: review and proposed interventions

This section sought views on the review into app security and privacy, including its scope and the proposed voluntary Code of Practice. This included the rationale for the Code, its potential impact and whether any additional interventions should be considered.

7.1 Question 8: Do you agree with the review including all types of app stores within its scope (e.g. stores for mobile devices, smart wearables, voice assistants, gaming stores, etc.) regardless of where their operators are based or what type of device they support?

• Yes	85%
  No	7%
  Don’t know	9%

Base figure: 46 responses

A total of 46 responses were recorded both from individuals and organisations. Of those, 23 respondents included additional supplementary qualitative responses. The vast majority of respondents (39) agreed with the review including all types of app stores within its scope regardless of where their operators are based or what type of device they support. Only three respondents did not agree with the review including all types of app stores within its scope and four participants responded ‘don’t know’.

Seven supplementary qualitative responses were recorded excluding those that did not answer the question directly. The majority of respondents suggested either broadening or clarifying the definitional scope of the work, such as incorporating apps linked to devices and explaining if particular stakeholders were out of scope of the Code of Practice. Other topics that emerged from responses involved incorporating open source applications within the work and the need for factoring in new players in the operating system or app store ecosystem.

7.2 Government response

We have added and defined new terms in the updated Code of Practice and explained which stakeholders need to adhere to the Code so there is greater clarity on the scope of the Code. Open source applications are already covered by this work because the Code’s security and privacy requirements apply to all app developers. With regards to apps linked to devices, future secondary legislation within the Product Security and Telecommunications Infrastructure Bill will provide clarity on this. The government will engage further with industry ahead of bringing forward this secondary legislation. We have also considered potential changes to the app ecosystem when producing the updated Code.

7.3 Question 9: Are there any additional security and privacy issues or bad practice in the app ecosystem that you would like to raise separate from those in the publication document?

• Yes	54%
  No	26%
  Don’t know	20%

Base figure: 46 responses

A total of 46 participants provided responses for this question. Of those, 25 respondents agreed that there were indeed additional security and privacy issues in the app ecosystem separate to those in the publication document. There were 12 respondents who disagreed with the aforementioned question and 9 participants responded ‘don’t know’.

For this question, 20 qualitative responses were noted excluding those that did not answer the question directly. The most common theme from respondents noted issues around the collection, storage, permissions and use of personal data. Respondents additionally flagged problems around the extensiveness of operator’s checks on apps and their market power in being able to decide if an app was safe or not. The respondents further noted a lack of understanding in the developer community on what were suitable mitigations as well as security and privacy practices for building and managing apps. A few respondents also highlighted issues around the validity of reviews for apps, inaccurate age ratings for apps and a lack of compliance to data protection law. Issues on the supply chain of app stores were also flagged.

Other notable points raised by respondents include risks surrounding the manufacturing and selling of spyware software marketed as employee or child monitoring software. Additionally, a respondent noted that the functionality of the apps could be a security and privacy concern, such as if an app has the capability to analyse voice data even after the audio is muted. Some respondents also raised issues around the inability to understand the behaviour and data practices of software development kit providers.

7.4 Government response

New provisions have been added to the Code and further clarifications provided regarding requirements set out in data protection law around the collection, storage, permissions and use of personal data (see Principle 5.2 and 5.3 as well as Annex A). We have also added a new provision (see Principle 1.3) to increase transparency on operators’ security checks for apps and updates. Further provisions have also been added specifically on the functionality of apps and in relation to software development kits (see Principle 2.2, 2.3 and 4.2). We have also created a new principle (Principle 2) that sets out baseline security and privacy requirements for apps to address concerns that developers do not understand how they should appropriately build apps. We have also removed wording in the Code on reviews for apps in light of the feedback provided. The feedback surrounding age ratings is outside the scope of this work, but we would encourage operators to consider this within their app store processes to make sure apps have consistent age ratings.

7.5 Question 10: Do you support the need for a voluntary Code of Practice for App Store Operators and Developers that sets out baseline security and privacy requirements?

• Yes	83%
  No	13%
  Don’t know	4%

Base figure: 48 responses

In total there were 48 responses to this question. Of those that responded, 40 respondents supported the need for a voluntary Code of Practice. Six respondents did not support the need for a voluntary Code of Practice and two participants responded ‘don’t know’.

As the chart indicates, the vast majority of respondents supported the need for a voluntary Code. A total of 35 respondents provided supplementary explanations for their response (excluding those that did not explicitly answer the question). The most common theme from those that provided feedback alongside their “yes” answer was that they advocated taking forward regulation. Interestingly, the most common theme from those that said “no” to the question was that they felt the Code should be mandated.

Several other themes were raised as reasons for why the Code is needed, including that there was a clear threat profile and the Code would help improve user trust and create more transparency. Moreover, some respondents flagged that it would increase compliance with current laws (such as data protection). Other respondents noted that the Code needs to be taken forward alongside an international approach and should be tied in with current work led by certification and assurance companies as well as professional bodies. A few respondents also noted the importance that operators and developers take steps to comply with higher security and privacy requirements beyond what is set out in the Code. A further stakeholder was of the view that a rigorous app review (process) alongside security measures (from the Code), will enable small developers to compete on the same footing as bigger companies with global name recognition.

7.6 Government response

We welcome the scale of support for the proposed voluntary Code of Practice and have published an updated version of the Code alongside this document. We encourage app developers and app store operators to take urgent action to adhere to the Code’s principles. Operators and developers can highlight their adoption of the Code by declaring this on their company website, app website or app store. These stakeholders should also inform DCMS by emailing [email protected]

We will continue to work with international partners to advocate an international approach in this area based on the Code’s requirements so that we reduce the burden on stakeholders in the app ecosystem. We will also be working closely with assurance scheme providers because we want to collaborate with industry to offer app store operators that adhere to the Code, but also those that go above and beyond the Code, with the ability to highlight this publicly.^{[footnote 10]}

7.7 Question 11: Would there be any challenges (costs, resources, etc.) from implementing the Code of Practice that has not been set out in the publication document?

• Yes	46%
  No	12%
  Don’t know	41%

Base figure: 41 responses

Of a total of 41 responses, 19 respondents agreed that there would be challenges when implementing the Code of Practice. 5 participants responded ‘no’ to the following question and 17 respondents said they ‘don’t know’.

Excluding the responses that did not directly respond to the prompt, 13 supplementary responses were recorded for this question. The most common theme that respondents noted was that there would be a cost to developers, such as accessing toolkits and putting more resources into building apps. There were several other themes identified from the responses, this included a cost to app store operators, such as more resources for pentesting and scanning apps. Moreover, there could be a further adherence cost on implementing the Code depending on whether the requirements were adopted internationally and by other bodies. Additionally, there could be potential costs for creating new tools or in educating developers and a broader cost of reporting adherence with the Code. Other notable responses included the potential for increased liability for app store operators (depending on if the Code was enforced in the future) and that an onerous app review process might discourage developers and platform owners from implementing the Code.

7.8 Government response

We recognise that any new set of security and privacy requirements will bring additional costs and other challenges to stakeholders that are part of the app ecosystem, particularly app developers and app store operators. However, we believe that protecting users should be a priority for all stakeholders. We’ve therefore created the updated Code with consideration of the costs to both app developers and app store operators in implementing it.

7.9 Question 12: Are there other interventions that the government should consider to help protect users from malicious and insecure apps whilst ensuring that developers meet security and best practice?

• Yes	80%
  No	9%
  Don’t know	11%

Base figure: 45 responses

A total of 45 responses were recorded for this question, the vast majority (36 respondents) answered ‘yes’ whilst 4 respondents answered ‘no’ and the remaining 5 participants responded ‘don’t know’. Of the 45 respondents that answered yes, 32 respondents provided supplementary qualitative responses.

31 respondents provided an explanation for their response, excluding those that did not answer the question. The most common intervention highlighted by respondents was to introduce a reporting system or certification scheme for developers of apps. The second most common theme underlined the importance of consumer guidance and awareness campaigns. There were several other proposals, this included facilitating the creation of an information exchange, such as between app store operators and small businesses. Additionally, respondents recommended certification for app stores or app developers, mandating parts or all of the Code and providing further resources and encouraging more enforcement action from the Information Commissioner’s Office (ICO). A few respondents also recommended guidance for small businesses in the app supply chain. Other notable responses included the need to engage with international partners to create an aligned approach on the Code’s requirements.

7.10 Government response

Interventions being taken forward

Stakeholders repeatedly mentioned during meetings with the government, and in their responses to the Call for Views, that the UK should prioritise creating international alignment on the Code’s security and privacy requirements. We want to ensure that the UK takes a collaborative  approach given the global nature of the app market. We plan to continue our engagement with international counterparts to promote the need for requirements, particularly in the context of future competition regulation. Following this publication, we will undertake work to explore the viability of creating an international standard based on the Code.

Interventions which will be kept under consideration

We will keep consumer guidance and an awareness campaign under consideration for the future. This is because neither intervention would be effective at this time because operators and developers need to have the adherence period to create a function for relevant security and privacy information to be offered to users. We also want to ensure that any campaign aligns with the objectives of the Cyber Aware campaign which coordinates all of the government’s cyber comms efforts focused on consumers. However, we will keep this under review as we recognise that in some specific circumstances, such as FluBot, NCSC guidance was produced to help protect users. Once the information set out in the Code is more readily available on platforms, the government will then work with consumer groups and regulators to determine if guidance or an awareness campaign would be useful.

We will also monitor whether certification for app stores or app developers is needed. We do not advocate UK government-led certification without international alignment on the requirements because any scheme could be negatively viewed by many in industry as the UK taking an isolationist approach. We believe it is important to prioritise building support for the Code’s requirements rather than further differentiating ourselves from other countries, particularly when the competition regulatory landscape could change in the coming years. Certification would also cause increased adherence costs to operators and developers. We also recognise that there is a well-established industry for creating certification schemes and we want these companies to create programmes that go beyond the Code’s baseline requirements. This will further increase protections for users and will offer operators and developers the ability to positively differentiate themselves from their competitors.

With regards to training, guidance and an awareness campaign for developers and small businesses, we have signposted NCSC guidance and other standards throughout the revised Code of Practice. The guidance noted in the document includes areas, such as vulnerability disclosure, secure supply chain management and some specifically for developers. They will support stakeholders with adhering to the Code. Additionally, adherence with principles one and six, will in part require operators to signpost additional guidance to help app developers adhere to the Code.

The government will conduct further engagement with developers and small businesses in the coming months to understand if they are facing any issues linked to adherence with the Code. We will therefore keep these interventions under consideration in case we receive specific feedback that highlights where any further government involvement can be effective. Additionally, the ICO will explore the development of further tools and guidance to explain the concepts of data protection by design and default.

Interventions not being taken forward

In terms of setting-up an information exchange, we recognise that said forum could offer benefits to app store operators through sharing threat data that could result in the removal of malicious apps. This would ultimately help protect their customers. However, we think it would be more effective for operators to regularly publish information on the vulnerabilities found on their app stores to inform other operators and the wider industry. This will in turn create more transparency and help protect users from malicious apps that have been previously found on an app store. We recognise that this information should be disclosed in a format that does not help malicious actors.

The Code has been expanded to include detailed information on relevant data protection law to provide greater clarity for app store operators and app developers. Following publication of the Code, we are minded to conduct independent research to assess whether the Code’s requirements are being followed. Additionally, we hope that by setting out in Annex B within the Code how stakeholders can report security and privacy concerns to the ICO, this will help increase compliance to data protection law.

8. Section 2: Code of Practice principles

This section looked at gathering views on the seven principles laid out in the Code of Practice. The section asked about each principle and whether they should be included within the Code. The questions in this section also asked respondents if there were other principles that could be included in the Code.

8.1 Question 13 Principle 1: Ensure only legitimate apps that meet security and privacy best practices are allowed on the app store. Do you support the inclusion of this principle within the Code of Practice?

• Yes	87%
  No	6%
  Don’t know	6%

Base figure: 47 responses

In response to this question, a total of 47 respondents were recorded. Of those, 41 respondents agreed that only legitimate apps that met security and best practice should be allowed on app stores and this principle should be included within the Code of Practice. Only 3 respondents disagreed with this principle being included within the Code of Practice and 3 participants responded ‘don’t know’.

Of the 47 respondents, 25 provided a qualitative response for this question. The most common response was that there should be transparency on the app store vetting processes. The second most common response highlighted the need for further clarity on wording and phrasing of this principle. Other themes drawn from responses included the need for further detail on the GDPR requirement in the Code, clarity on the security and privacy components and that there should be a timeframe in which malicious apps should be removed from an app store. Some respondents also noted that there should be a process in which you can appeal once an app has been removed from an app store and that the reviewing process should involve humans rather than just automated responses.

Other notable points included that apps need to be continuously monitored for compliance and that developers need to disclose details about the privileged access of applications and seek consent for specific tasks. A stakeholder also recommended removing the provision on operators needing to detect and report apps that spoof known legitimate brands because it was not their responsibility to deal with this.

8.2 Government response

Subsequent to the Call for Views, within the Code, we have provided more clarity on the data protection requirements (see Annex A and Principle 8). We have clarified the scope of some provisions and the broader principle through an amendment to the title. We believe the point on transparency has been addressed through changes in the principle, specifically Principle 1.1 and Principle 1.3. We have added a timeframe for removing malicious apps (see Principle 1.5) as well as some definitions for key terms (see background section of Code). We have also removed the provision linked to reporting apps that spoof known legitimate brands and instead have placed the onus on developers to flag said apps to operators (see Principle 1.4).

8.3 Question 14. Principle 2: Implement vulnerability disclosure processes. Do you support the inclusion of this principle within the Code of Practice?

• Yes	87%
  No	2%
  Don’t know	11%

Base figure: 46 responses

A total of 46 responses were recorded for this question. Of those that responded, the majority (40 respondents) agreed that principle 2 should be included within the Code of Practice. Only 1 respondent disagreed with principle 2 being included in the Code of Practice and 5 participants chose the ‘don’t know’ option.

For this question, 21 qualitative responses were recorded excluding those that did not answer the question directly. The most common piece of feedback was that the government should signpost well-established existing standards. This was closely tied with feedback from some other stakeholders who noted the need for a framework or guidance for developers on vulnerability disclosure. Other themes raised included the need to set a timescale for actioning a security issue, clarity on what is expected from operators and highlighting support for the public reporting of issues found in apps. Further themes revolved around the need to consider the impact of requiring vulnerability disclosure on new apps or small developers with a few stakeholders opposing the requirement as it might be too burdensome for developers.

8.4 Government response

The government has now signposted relevant standards and guidance in the Code to assist developers. We have also added some additional provisions to clarify the responsibilities of app store operators (see Principle 3.2 and 3.3). These provisions include details on the timescale for actioning a response if the developer does not respond to a vulnerability disclosure report.

8.5 Question 15. Principle 3: Keep apps updated to protect users. Do you support the inclusion of this principle within the Code of Practice?

• Yes	95%
  No	0%
  Don’t know	5%

Base figure: 43 responses

There were 43 responses to this question, nearly all (41 respondents) agreed that this principle should be included within the Code of Practice, with no respondents disagreeing and only 2 participants providing the response of ‘’don’t know’’. Of those that responded to this question, 28 participants provided supplementary qualitative responses.

Of the 43 total respondents, 18 provided a supplementary explanation for their response (excluding the ‘did not answer’ category). The most common piece of feedback was the need for clarity on the timescale expectations for developers to patch a vulnerability as the Code in its draft form noted “as soon as they are identified”. Other themes from the feedback included new requirements, such as removing apps that are no longer supported and checking all developers’ apps if one is found to be malicious. Some respondents highlighted that further clarity was needed on whether third-party software was included.

8.6 Government response

We have removed the wording “as soon as they are identified” to provide flexibility to operators and developers in determining an appropriate timescale and process for patching vulnerabilities (see Principle 4.1). With regards to support periods, we recognise that many apps are created by hobby developers. We also acknowledge that apps don’t necessarily need to be updated frequently because they may have limited functionality. However, there are many apps available on app stores that have not been updated for a long time. We have therefore added a provision that requires operators to test the developers’ vulnerability disclosure contact details if an app hasn’t been updated for two years (see Principle 4.5).

The period of two years was chosen to not overly burden operators whilst also ensuring that apps are not left on a store which are no longer supported by a developer. This will allow the operator to determine if the disclosure process still functions. If operators do not receive a response within 30 days, then they shall make the app unavailable on the store. We have added a further provision in another section of the Code to address the feedback around checking all developers’ apps if one is found to be malicious (see Principle 1.6). We have also included a new provision on the need for Developers to update their apps when a third party library or software development kit receives a security or privacy update so that users are protected (see Principle 4.2).

8.7 Question 16. Principle 4: Provide important security and privacy information to users in an accessible way. Do you support the inclusion of this principle within the Code of Practice?

• Yes	91%
  No	0%
  Don’t know	9%

Base figure: 43 responses

A total of 43 respondents answered this question with nearly all (39 respondents) agreeing that this principle should be included within the Code of Practice. No respondents disagreed with this principle being included within the Code of Practice and 4 participants responded ‘don’t know’.

For this question, 24 qualitative responses were noted excluding those that did not answer the question directly. The most common theme from the responses revolved around providing further clarifications to account for a host of different situations. The second most common theme brought out competing views on if and how users should be notified when an app is no longer supported. A further theme focused on problems with trusting reviews for apps. Some respondents flagged that the principle needed to find a balance in terms of not burdening users with information whilst others flagged that the principle needed a provision around increased transparency for terms and conditions. Lastly, a few stakeholders noted that data protection law already covers aspects of the principle.

Other notable points from the feedback included opposition to the government requiring the location of the app developer and clarity on a consumers’ rights in particular situations. Several stakeholders also provided helpful wording suggestions to ensure the scope of some provisions was clear.

8.8 Government response

We believe further clarification in other parts of the Code, including the background section, address the points on scenarios raised in this question. We have removed part of a provision on reviews in light of the concerns raised about fake reviews for apps. We also removed the need for a developer’s location to be displayed to users as we felt this might stifle innovation. To address the point around balance, we have added a new requirement that developers should provide various information about their app’s data practices and operators should signpost this information to users (see Principle 5.2 and Principle 5.3). We have also clarified expectations about information linked to permissions (see Principles 5.4). We have also clarified in the Code how this principle aligns with data protection law (see Annex A) and in this document, we have added a section on page four which provides an overview of relevant consumer protection laws.

8.9 Question 17 Principle 5: Enterprise app stores shall be secured where provided. Do you support the inclusion of this principle within the Code of Practice?

• Yes	87%
  No	0%
  Don’t know	13%

Base figure: 38 responses

In response to this question, 38 responses were recorded. 33 respondents agreed that this principle should be included within the Code of Practice with no respondents disagreeing and 5 responding ‘don’t know’.

For the following question, 11 qualitative responses were recorded. The joint most common themes were that there were liability circumstances if operators had responsibility for the security of enterprise app stores, and organisations that create app stores for their employees should comply with the Code. A further theme was around the need for coherence and clarity on data protection obligations for enterprise app stores and that this principle should not be in the Code as it does not apply to all app stores.

8.10 Government response

We have moved this principle into Annex C within the Code as it is only relevant to particular types of app stores. We have not expanded the scope of the Code to include an expectation that organisations who set-up enterprise app stores should adhere to the Code because this would fundamentally change the scope of the document. Additionally, we think users can be best protected by improving the practices of app developers and app store operators.

8.11 Question 18 Principle 6: Promote security and privacy best practice to developers. Do you support the inclusion of this principle within the Code of Practice?

• Yes	93%
  No	0%
  Don’t know	7%

Base figure: 42 responses

There were 42 responses to this question, with the majority (39 respondents) stating that this principle should be included within the Code of Practice. None of the respondents disagreed with the inclusion of this principle and only 3 participants stated that they did not know.

Of the 42 respondents, 21 provided a supplementary explanation. The most common theme from the responses centred around differing views on how ‘best practice’ and ‘standard requirements’ should be clarified and by who. Other themes included taking forward certification, noting any regulatory overlap with this principle and signposting to relevant publications and standards in this area. Several participants also recommended a change to the requirement on the supply chain to incorporate monitoring third party libraries. A further notable point included whether the government should support an information exchange between operators to share information about threats and vulnerabilities. Additionally, a stakeholder noted there may be liability problems for operators if they signpost best practice information to developers that is created by themselves.

8.12 Government response

We do not want to create liability issues for operators when the intention of this principle is to ensure that operators provide appropriate guidance to developers. We have therefore adjusted the title and noted that if best practice information is given, this could be highlighted by signposting to other app standards.^{[footnote 11]} In terms of the other feedback provided; we have clarified how this principle interlinks with data protection law within the new Annex A and addressed the point on third party libraries (see Principle 6.4). The suggestions around certification and an information exchange are addressed in the government response section for question 12.

8.13 Question 19. Principle 7: Provide upfront and clear feedback to developers by app stores. Do you support the inclusion of this principle within the Code of Practice?

• Yes	93%
  No	0%
  Don’t know	8%

Base figure: 40 responses

A total of 40 responses were recorded for this question. The majority (37 respondents) agreed that this principle should be included in the Code of Practice. No respondents disagreed and 3 participants answered ‘don’t know’.

Out of the 40 total respondents, 12 respondents provided qualitative feedback. The most common theme from the responses was that further detail was needed on the requirement that operators should provide feedback to developers if an app is rejected. Other themes included clarifying when feedback should be provided and some stakeholders felt operators would be reluctant to provide detailed feedback. Moreover, a few respondents noted that there was some overlap between this principle and data protection law as well as specific standards.

8.14 Government response

We have modified this principle by clarifying our expectations of operators to ensure that they provide clear and actionable feedback for developers (see Principle 7).

8.15 Question 20. Are there any principles missing from the current version of the Code of Practice?

• Yes	54%
  No	21%
  Don’t know	25%

Base figure: 48 responses

In total, 48 respondents answered this question. Of those, 26 said that additional principles should be added, 10 did not think any more principles should be included and 12 participants responded ‘don’t know’.

For question 20, 22 respondents provided additional qualitative responses. The responses could be broken down into three themes, overarching principles for all stakeholders in the app ecosystem (such as commitments to the user or to reduce risks as low as reasonably practicable), requirements for operators and requirements for developers. Some responses also noted the need to input scenarios, use-cases and more definitions into the Code. Several others used this question to make recommendations on other interventions as well as implementing the Code.

Notable suggestions for operators included ensuring they are providing small and medium enterprises with help understanding app store guidelines, protecting privacy and other software distribution challenges. There were also recommendations on ensuring operators provide responsive services for developers. Other ideas included signposting other relevant legislation in the Code of Practice and including a provision for operators that they must review an app’s coding. Moreover, responses noted that the government should set out language and iconography that operators should adopt when conveying security and privacy information and that government should include within the Code, a principle that addresses incidents and breaches.

In terms of principles for developers, notable points included that there should be a provision addressing minimum encryption and a separate one on the need for transparency about all features of an app. Furthermore, the government should consider the need for developers to perform continuous validation and testing.

8.16 Government response

The government’s aim is to create a Code of Practice that can be measured to check adherence. We have therefore decided to not include overarching principles in the document as suggested above as they would be challenging to test. We do however recognise how important it is that developers and operators take steps to protect users and their information. We have therefore added some additional provisions to strengthen the Code of Practice based on the feedback provided above.

In terms of new requirements for operators, we want to provide a degree of flexibility on how they choose to implement and differentiate themselves from their competitors. We therefore advocate giving operators the ability to decide how they structure and write their guidelines and convey information on their app stores to users. We believe the concerns around privacy, software distribution and operator responsive services are covered in the Code.

We have however amended the Code to require operators to publish an overview of their security checks; this will create transparency to help determine if they are complying with the Code (see Principle 1.3). With regards to new requirements for developers, we have added a provision to address the concerns around encryption and the functionalities of an app (see Principles 2.1, 2.2 and 2.3).

8.17 Question 21 Do you support the commencement of work to explore how the Code of Practice’s requirements could potentially be mandated in the future? (Noting that around the globe, there are various investigations and regulatory initiatives being progressed that have the potential to impact the regulatory system around mobile app stores).

• Yes	78%
  No	8%
  Don’t know	15%

Base figure: 40 responses

A total of 40 responses were recorded for this response. Of those, 31 supported the commencement of work to explore how the Code of Practice requirements could potentially be mandated in future. Only 2 responded ‘no’ and 6 participants said ‘don’t know.

Out of the total 40 respondents, 18 respondents provided a supplementary explanation. The most common response was that exploratory work was justified as there was a clear threat profile. Other themes included that the government needs to build international engagement simultaneously with any regulatory exploratory work and that there is a need for a consultation process to test any future proposals with stakeholders. Some stakeholders also indicated support for exploratory work, but sought clarity on its scope. The most common answer from those that stated ‘no’ to this question was that it was too early to mandate.

Other notable points from the feedback include that “the majority of consumers are likely to assume that many or all of the protections outlined in the consultation are already in place so mandating them will serve the purpose of bringing app store policies up to current public assumptions”. Another respondent noted that voluntary schemes are too easy for operators and developers to ignore without any real consequence.

8.18 Government response

There is significant support for the government to start exploratory work to examine how the Code’s requirements, not already mandated in law, could be legislated. We will therefore start work following the publication of the Code to determine what levers are available.  However any decisions on whether to progress with regulatory proposals will depend on the findings of our research to assess adherence with the Code and the effectiveness of said adherence (as elaborated in the Code’s background section). Moreover, any future proposals will need to be thoroughly tested with stakeholders through consultations and the development of further evidence.

8.19 Question 22 Is there any other feedback that you wish to share?

• Yes	24%
  No	70%
  Don’t know	5%

Base figure: 37 responses

A total of 37 responses were recorded for this question. Of those that responded, 9 respondents shared feedback and 26 chose not to share feedback. Two said that they did not know.

For this question, 8 qualitative responses were recorded excluding those that did not answer the question. Two themes emerged from the feedback from respondents; this included the need for a governance structure for the Code which ensures that roles and responsibilities are clearly defined, and that the government should enforce or help enforce the current legal regime, (such as data protection law).

8.20 Government response

The Code will be voluntary, therefore it would not be appropriate to put a governance regulatory structure in place at this time. However, we have provided detail within the Code on how the government will check adherence with the Code’s principles. It is important to note that there are also enforceable obligations set out in existing legislation within the Code. This is specified within the Code of Practice.

1. DCMS commissioned mapping by Copper Horse Ltd, ‘Application Security Mapping’, November 2022. https://appsecuritymapping.com/ We have also commissioned a mapping by Copper Horse Ltd of the global app store landscape (completed in December 2022). This can be found at: https://appstoresoftheworld.com/ ↩

2. IBISWorld Ltd, ‘App Development in the UK’, Industry Report SP0.186, May 2022. For more information see www.ibisworld.com/united-kingdom/market-research-reports/app-development-industry/ ↩

3. https://www.statista.com/topics/1002/mobile-app-usage/#topicHeader__wrapper Date accessed: 15 August 2022 ↩

4. https://www.statista.com/topics/1002/mobile-app-usage/#topicHeader__wrapper Date accessed: 15 August 2022 ↩

5. For context, the specific articles include 4(7), 4(8), 5(a), 5(1), 5(2), 12-14, 25, 26, 28-36, 58 and 83. ↩

6. See the government’s proposals for amendments to the NIS Regulations and the response to Call for Views for further information. (add link) ↩

7. In Wales, the NHS Wales Cyber Resilience Unit supports Welsh Ministers as the Competent Authority on implementation of the UK’s Network and Information Systems (NIS) Regulations for the health sector in Wales. It provides challenge, support and an assurance function, in operationalising the Regulations within health care settings in Wales. The Unit is also responsible for reporting to Welsh Ministers on the status of the NHS Wales cyber posture against the NIS Regulations. ↩

8. Government response to the consultation on the pro-competition regime (2022) ↩

9. Transforming for a digital future: 2022 to 2025 roadmap for digital and data, 9 June 2022: https://www.gov.uk/government/publications/roadmap-for-digital-and-data-2022-to-2025/transforming-for-a-digital-future-2022-to-2025-roadmap-for-digital-and-data ↩

10. We are taking steps to ensure that government apps will adhere to the requirements in the Code of Practice. The government may need to consider how to balance security and digital access to government apps on app stores, particularly as the market diversifies, to ensure people can access important information and services. ↩

11. DCMS commissioned Copper Horse to conduct a mapping of app store and app security standards. ↩