Guidance

Acceptable Use Policy for the DVS Hub

Published 15 October 2026

Important

The DVS Hub is currently provided to support Sandbox onboarding, account administration, technical questions, bug reporting, vulnerability reporting and incident reporting. This version does not govern production support or production-onboarding evidence.

1. About this Policy

1.1 This Acceptable Use Policy (“Policy”) governs access to and use of the GOV.UK Wallet DVS Support Hub (“Hub”), a custom portal delivered using ServiceNow technology by the Department for Science, Innovation and Technology (“DSIT”), acting through the Government Digital Service (“GDS”).

1.2 Separate platform, privacy or cookie notices may apply where displayed. This Policy applies in addition to those notices.

1.3 By logging in to or using the Hub, the DVS and its nominated User (that has been provided with a Sandbox account, which is continuing, and is exercising access to the Hub pursuant to it) accepts the current version of this Policy. If either the DVS or such nominated User (referred to as “User” in this policy) does not accept it, the User must not access or use the Hub.

1.4      The DVS remains at all times responsible for the acts and omissions of  all Users for whom the DVS has requested Hub access and for the DVS Lead (as defined below). The actions and/or omissions of a DVS Lead or a User will be treated as the actions of the DVS and all references in this Policy (and for the purposes of applying the Terms of Use) will be construed accordingly. Each DVS will ensure that its Users act at all times in accordance with and shall not contravene this Policy.     

2. Permitted purpose

2.1 The Hub may be used only for activities that properly relate to use of GOV.UK Wallet Sandbox and which are made available through the Hub (each a “Permitted Purpose”), including:

• onboarding and eligibility activity;
• user and access management;
• technical support questions;
• functional bug reporting;
• security vulnerability reporting;
• incident reporting.

2.2 The Hub must not be used for anything other than a Permitted Purpose.  Without limitation to that statement, the Hub shall not be used for certificate management, service announcements, publication of documentation, general relationship management, production support or production-onboarding evidence unless GDS expressly expands the Hub’s scope in a later version of this Policy or related guidance.

3. Accounts and access

3.1 Every User must have an individual named account for accessing the Hub. Shared, generic, transferred or borrowed accounts are prohibited.

3.2 3.2 The DVS will appoint an organisational administrator and/or DVS representative for the purposes of communication concerning DVS onboarding onto and operations within Sandbox (to be referred to as the “DVS Lead”) and will notify GDS of the name and contact details prior to any User exercising any access to the Hub.  The DVS Lead is responsible for creating and requesting the removal of accounts for people approved by the DVS. Access may be given to DVS employees, individual contractors, subcontractor personnel and others approved by the DVS in pursuance of a Permitted Purpose.

3.2.1 Following onboarding, the DVS Lead will have access to onboard Users within the organisation through DVS Support Hub.

3.2.2 Every additional User must hold an individual named account, which shall be linked to the appropriate DVS organisation within the Hub portal.

3.2.3 Each User is required to log in using their own credentials and accept the terms of this Policy prior to exercising access to the Hub.

3.2.4 The DVS Lead shall submit an offboarding or access-modification request to GDS where:

• a User departs the organisation;
• a User changes role or duties;
• a User’s access needs are updated; or
• a User no longer maintains a genuine business need for access.

3.2.5 Should the nominated DVS Lead be replaced, the incoming DVS Lead must satisfy the relevant initial onboarding and verification procedures before GDS provides organisational administrator access. Onboarding a new DVS Lead does not automatically transfer the outgoing Lead’s permissions.

3.2.6 Following successful completion of the necessary checks and provisioning of access for the replacement DVS Lead, the DVS must promptly request the amendment or removal of the former DVS Lead’s account rights.

3.3 The DVS must:

• ensure each User has a genuine business need for access;
• verify each User’s identity;
• keep names, roles and contact details accurate;
• Request removal or amendment of access when a User leaves, changes role or no longer needs access;
• review access periodically;
• remain responsible for the access and activity of contractors and subcontractors;
• notify GDS of routine access changes within three business days; and
• notify GDS immediately, and no later than 24 hours after discovery, of suspected account or credential compromise.

3.4 The DVS must ensure that:

3.4.1 Users protect usernames, passwords and multifactor authentication details;

3.4.2 Users must not share authentication factors, bypass or weaken multifactor authentication, or configure browsers, tools or services in a way that exposes credentials; and

3.4.3. each User complies with the Policy at all times and does not do anything that would put DVS in breach of the Terms of Use

3.5 If a device on which Hub authentication details are stored is lost or stolen, the DVS must notify GDS promptly so that the account can be locked or disabled.

4. Inactive accounts

4.1 An account that remains inactive for 60 days may be disabled. GDS intends to issue warning emails after 30, 50 and 59 days of inactivity, but reserves the right in its discretion to disable accounts without prior warning including where GDS in its discretion considers it appropriate  for security or administration purposes.

4.2 A disabled account may be reactivated through the current access process. It may be permanently deleted after 60 days. Ticket, audit and security records may be retained separately under GDS’s records-retention policy.

5. Information that may be submitted

5.1 Users will provide the information reasonably necessary in pursuit of  a Permitted Purpose, which as a minimum will include:

• business contact details required to administer named accounts;
• organisational and certification information;
• technical questions and Synthetic Data;
• sanitised API request and response examples;
• sanitised screenshots, logs, traces and configuration extracts;
• architecture information the DVS is authorised to share;
• bug reports, vulnerability reports and incident information.

5.2 “Personal Data” has the meaning given by applicable UK data protection law and includes information that identifies, relates to or can reasonably be linked to a real person. The Hub necessarily processes limited business contact information for named Users, but Users must not include any other Personal Data in tickets, free-text fields, logs, screenshots or attachments.

5.3 Before submitting material, the User must review and sanitise it by removing Personal Data, live identifiers, credentials, secrets, unrelated information and third-party information the DVS is not authorised to disclose.

5.4 Production-derived code or configuration may be submitted only where the DVS has the right to share it and it has been sanitised in accordance with this Policy. Production logs and screenshots must not be submitted unless fully sanitised.

5.5 The DVS Lead will be responsible for reviewing and verifying information provided by Users and monitoring their activities to ensure compliance with this Policy.

6. Prohibited information and files

6.1 Users must not submit or upload information relating to any of the below (“Prohibited Information”):

• citizen, customer or other Personal Data (including without limitation special category Personal Data), except the limited business contact information needed to administer Users;
• production credential data, live credentials or copies of identity documents;
• payment-card or bank-account information;
• passwords, private keys, API secrets, active access tokens, recovery codes or other authentication secrets;
• unredacted or unsanitised production logs, screenshots, traces or payloads;
• public certificates or certificate signing requests, because certificate management is administered outside the Hub;
• malware, executable files, destructive content or material designed to compromise a system;
• third-party confidential information the DVS is not authorised to share; and/or
• commercial lobbying material or information unrelated to GOV.UK Wallet support.

6.2 If a User cannot safely sanitise information needed for a security or incident report, the User must submit a high-level report without the sensitive evidence and wait for GDS to provide an approved alternative channel.

6.3 If Prohibited Information is submitted accidentally, the User must notify GDS promptly, avoid further access to or dissemination of the information, and cooperate with any containment, deletion or investigation steps required or reasonably expected by GDS.

7. Creating and managing requests

7.1 Each User is required to:

• select the most appropriate request or incident category;
• provide a clear and accurate description;
• include relevant steps to reproduce the issue;
• identify the applicable environment and documentation version;
• avoid duplicate requests where an existing request can be updated;
• respond to reasonable requests for relevant information;
• confirm resolution or closure where requested.

7.2 Users will not knowingly submit inaccurate reports, misuse incident priority or severity classifications, repeatedly reopen resolved matters without new relevant information, or impersonate another person or organisation.

7.3 Users will communicate professionally, relevantly and respectfully. Abusive, threatening or otherwise inappropriate communications are not allowed and will result in termination of the account.

8. Automated and technical misuse

8.1 Users are not permitted to use bots, scripts, scraping tools, ServiceNow APIs, automated ticket creation, automated browser tools, AI agents or integrations with another ticketing system to access or use the Hub unless GDS expressly enables and authorises that use in writing outside the Hub.

8.2 Users will not probe, scan, test, interfere with, bypass controls in, reverse engineer, disrupt or attempt unauthorised access to the Hub, ServiceNow, GDS systems or another DVS’s information.

8.3 GDS may block uploads, quarantine material or suspend an account where malicious or undesirable material is detected. Suspension may be protective and does not imply that GDS considers the account holder to have acted maliciously.

9. Security vulnerabilities and incidents

9.1 The Hub is the normal reporting route for DVS Hub security vulnerabilities and incidents. A security report is required to be made by a DVS in the event of any discovery of a security vulnerability or incident and will include, to the extent safely available:

• the affected component;
• the date and time of discovery;
• a description and potential impact;
• the steps taken before discovery;
• the minimum information needed to reproduce or understand the issue;
• whether credentials or Personal Data may be affected;
• contact details for follow-up.

9.2 A User must not place highly sensitive or potentially exploitable evidence in the initial report. The User should submit a high-level description and wait for GDS to arrange any necessary follow-up through an approved channel.

9.3 If the Hub is unavailable and the DVS needs to report a P1 incident, as defined in the current Service Onboarding Pack, the DVS may use govukwallet-dvs-onboarding@digital.cabinet-office.gov.uk .

10. Information segregation

10.1 Users should only access tickets and information belonging to their own organisation. A User who can see another organisation’s information must immediately:

• stop accessing it;
• not copy, alter, download or share it;
• report the issue through the Hub, or through the P1 contingency route if appropriate;
• delete any local copy obtained inadvertently;
• follow GDS’s reasonable instructions.

11. GDS use and management of Hub information

11.1 GDS may use information submitted through the Hub for service delivery and support; product and documentation improvement; security and incident management; compliance enforcement; aggregate service reporting; audit; fraud and misuse prevention; and legal or regulatory compliance.

11.2 Access to DVS accounts may be provided by GDS, in pursuance of  the purposes set out in paragraph 11.1, to administrators, support staff, product and technical teams, security staff, relevant decision-makers utilised by GDS in respect of the Hub (whether GDS/DSIT or contractor personnel).  Such personnel shall be collectively referred to as “GDS Agents”. Information will not routinely be shared with other government departments through the Hub. References in this Policy to GDS shall be deemed to include a reference to GDS Agents where the context permits.

11.3 GDS may log and monitor authentication, account activity, tickets and amendments, downloads and attachments, administrative actions and security events for service operation, security, audit, incident investigation, compliance, fraud prevention and service improvement.

11.4 GDS may redact or delete prohibited data, quarantine or remove attachments, merge duplicate requests, amend severity or category, and archive or close inactive or resolved requests.

11.5 Each Hub record will be retained for 3 years, after which it will be deleted. Users may not be able to remove records after submission where GDS needs to retain them for security, audit, legal, operational or records-management purposes.

12. Service availability and support

12.1 The Hub is designed to be accessible 24 hours a day, 7 days a week, 365 days a year; it has a target availability of 99.9% per calendar month.  Any maintenance on the Hub will be communicated at least 7 days in advance. GDS does not provide an availability warranty or guaranteed service level in respect of the Hub and the Hub may be unavailable, changed, restricted or withdrawn at any time with or without notice and without any liability for GDS is so doing.

12.2 Standard support is expected to be staffed from 09:00 to 17:00, Monday to Friday, excluding applicable bank holidays. Out-of-hours monitoring or action will only be intended to be available for incidents meeting the current P1 definition as set out in Operational Guidance.

12.3 GDS provides support on a reasonable-efforts basis. There is no acknowledgement, response, resolution or fix-time service level. GDS may prioritise work by impact, risk, security and service need.

13. Status of responses and exceptions

13.1 Responses within the Hub are guidance only and Technical Documentation takes precedence. A response does not provide legal or regulatory advice, production approval, certification or assurance, and the DVS remains responsible for its implementation and decisions and shall rely on its own advice.

13.2 A Hub response cannot vary legal terms, an acceptable use policy, technical requirements or any other binding requirement, and cannot grant an exception to compliance with any of them.

13.3 Any exception must be requested and expressly authorised in writing through the designated email process outside the Hub. An exception is valid only if issued by an authorised GDS role and it identifies the scope, conditions and duration of the exception. There will be no deemed or implied waivers of compliance with each of the matters mentioned in paragraph 13.2.

14. Changes to this Policy

14.1 GDS may change this Policy from time to time with or without prior notice. Without limitation if GDS considers a matter to require urgent attention whether for security or legal reasons these  may take effect immediately.      GDS will provide notification as soon as reasonably practicable in accordance with the Terms of Use.

14.2 For a material non-urgent change, GDS will normally provide reasonable notice and may provide an implementation period of up to one month. Minor clarifications may take effect on publication or on the date stated in the notice.

14.3 Logging in to or continuing to use the Hub after a change takes effect constitutes acceptance of the revised Policy.

15. Enforcement and exit

15.1 GDS may take action in respect of actual or suspected misuse by warning the User, removing or quarantining material, suspending an individual account, or suspending all Hub accounts for the DVS with the choice of action being at GDS complete discretion.

15.2 GDS will at its discretion normally address individual misuse through the individual account first, unless the issue is organisational, repeated, linked to account compromise, or creates wider security, legal or service risk.

15.3 Material or repeated non-compliance may be considered in decisions about continued Sandbox participation or later progression. A protective suspension while an account compromise is investigated does not by itself establish wrongdoing.

15.4 When Hub access ends, accounts may be removed and open requests may be closed or archived. The DVS should preserve information it is independently required to retain before access ends. Confidentiality and GDS records-retention requirements continue after exit.