contract between the driver and vehicle licensing agency ...€¦ · vodafone and dvla technical...

of 105

Protect Commercial

Protect Commercial

The following handling instructions apply to this document:

Handle, use and transmit with care

Take basic precautions against accidental compromise, opportunist or deliberate attack

Dispose of sensibly by destroying in a manner to make reconstruction unlikely

Contract between the

Driver and Vehicle Licensing Agency

and Customer Name for

The Provision of a Non Fee Paying

Keeper at Date of Event (KADOE) Service

Version 5.0 – July 2013

© Crown copyright 2013

of 105

THIS CONTRACT IS BETWEEN: (1) The Driver and Vehicle Licensing Agency (DVLA), Longview Road,

Morriston, Swansea SA6 7JL, on behalf of the Secretary of State for Transport: and

(2) Customer Name, Address

The Contract covers the Provision of the non fee paying Keeper at Date of Event (KADOE) Service between DVLA and Customer Name as defined in this document. The Contract does not confer on Customer Name exclusive rights to this or any other parts of DVLA‟s business. The Contract constitutes the entire understanding between the parties and supersedes all prior representations, writings, negotiations or understandings with respect to this Service. Signed for and on behalf of Customer Name Name: Signed: Position: Date: Signed for and on behalf of DVLA: Name: Signed: Position: Head of Commercial Services Group Date: Version 5.0 – July 2013 © Crown Copyright 2013

of 105

Contents BACKGROUND TO DVLA GENERAL TERMS AND CONDITIONS 1.1. Law 1.2. Duration of the Contract 1.3. Return of Signed Contract 1.4. Duty of Care 1.5. Service Provision Performance 1.6. Meetings 1.7. Inspection 1.8. Payment 1.9. Corrupt Gifts and Payments of Commission 1.10. Freedom of Information and Disclosure of Information 1.11. Discrimination 1.12. Change of Control 1.13. Suspension of the Service 1.14. Termination of the Contract 1.15. Break 1.16. Consequences of Termination and Break 1.17. Assignment, Sub-Contractors and Suppliers 1.18. Loss or Damage 1.19. Data Protection 1.20. Insolvency 1.21. Retention of Documentation and Audit Access 1.22. Serving of Notices 1.23. Dispute Resolution 1.24. Severability 1.25. Transfer of Responsibility 1.26. Waiver 1.27. Rights of Third Parties 1.28. Force Majeure 1.29. Conflict of Interest 1.30. Intellectual Property Rights 1.31. Change Control Procedures 1.32. Use of Brands, Logos and Trade Marks 1.33. Use of DVLA‟s Name SCHEDULE 1 – DEFINITIONS AND INTERPRETATIONS SCHEDULE 2 – SERVICE DESCRIPTION 2.1. Purpose 2.2. Details of Provision 2.3. Background 2.4. Demonstrable Business Need 2.5. Actual Data Need

of 105

2.6. Internal Compliance Regime 2.7. Quality of Records 2.8. Input / Output Data 2.9. Conditions of Use 2.10. Additional Conditions of Use for Intermediary Companies 2.11. Security Requirements 2.12. Distribution of Records 2.13. Storage of Records 2.14. Audit and Assurance 2.15. Legal and Regulatory Compliance 2.16. Service Availability 2.17. Continuity of Service 2.18. Administration of the Contract 2.19. Business Query Support 2.20. Customer Representative 2.21. Compliance with Schedule 2 SCHEDULE 3- CHARGES AND PAYMENT 3.1. Background 3.2. Vodafone and DVLA Technical Set Up Charges 3.3. Payment of Set Up Charges 3.4. Audit Visit / Reconnection Charges 3.5. Variation of Charges 3.6. Value Added Tax SCHEDULE 4 – CHANGE CONTROL PROCEDURE

APPENDIX A: Permitted Purpose(s) APPENDIX B: ELISE KADOE External Interface Specification APPENDIX C: Customer Requirements and Guidelines APPENDIX D: Audit Compliance Requirements and Sample Audit Form APPENDIX E: Cabinet Office Mandatory Minimum Measures APPENDIX F: Off shoring Guidance APPENDIX G: Change Request Form APPENDIX H: Impact Assessment Form APPENDIX I: Change Authorisation Note ANNEX A: Points of Contact and Escalation for DVLA ANNEX B: Points of Contact for Customer Name

ANNEX C: Intermediary Companies

of 105

BACKGROUND TO THE DRIVER AND VEHICLE LICENSING AGENCY (DVLA) DVLA is an Executive Agency of the Department for Transport (DfT). Our main responsibilities are to:

maintain over 44 million driver records and 36 million vehicle records;

collect nearly £6 billion a year in vehicle excise duty;

limit tax evasion to no more than 1 per cent;

support the police and intelligence authorities in dealing with vehicle related crime.

Each year we handle around 200 million interactions and 120 million transactions which include:

17.6 million drivers transactions;

88.5 million vehicle transactions. Issue:

10.3 million driving licences;

17.3 million vehicle registration documents.

Receive:

19.7 million phone calls;

250,000 emails. DVLA is leading the way in government in providing electronic services to its customers. Our vision is to be a modern, highly efficient organisation, providing complete, accurate and up to date information and services that fully meet customer and stakeholder requirements. Our key purpose is to keep complete, accurate registers of drivers and vehicles and make them as accessible and as flexible as possible to those who have the right to use them. These registers underpin action by DVLA, the police and others to keep road users safe and ensure that the law is respected and observed; allow us to collect vehicle excise duty effectively and can be used to deliver other departmental and government initiatives such as traffic management and reducing carbon emissions. For more information visit www.gov.uk

http://www.gov.uk/

of 105

GENERAL TERMS AND CONDITIONS

of 105

1.1. LAW The Contract shall be governed by and interpreted in accordance with

English Law and shall be subject to the jurisdiction of the Courts of England and Wales.

1.2. DURATION OF THE CONTRACT 1.2.1 The Contract shall commence upon dated signature by DVLA and will

remain in force subject to termination or break in accordance with clauses 1.14 and 1.15.

1.3. RETURN OF SIGNED CONTRACT (existing electronic KADOE

customers only) 1.3.1 Failure of Customer Name to return a signed copy of the Contract within a

reasonable timescale will result in the suspension of the service until such time as a signed contract is received by DVLA.

1.4. DUTY OF CARE 1.4.1 DVLA shall perform the Service with all reasonable skill, care and diligence

and in accordance with all relevant legislative and statutory requirements. 1.5. SERVICE PROVISION PERFORMANCE 1.5.1 Customer Name shall properly monitor performance of the Service and

immediately inform DVLA Representative if any aspect of the Contract is not performed.

1.5.2 Customer Name shall exercise due care and propriety when dealing with

third parties in connection with the Contract and ensure that no commitments are entered into (unless expressly required under the Contract), without DVLA‟s prior written consent.

1.5.3 Nothing in the Contract shall be construed as creating a partnership, a

contract of employment or a relationship of principal and agent between DVLA and Customer Name. Nor should it be seen or portrayed as being an endorsement of any product or service offered by Customer Name.

1.5.4 DVLA will not be responsible for any works at Customer Name site or for

the establishment of the communication link to be used by Customer Name. Customer Name and if applicable Customer Name‟s Data Processor will need to separately arrange and pay for this work.

1.5.5 Customer Name, or if applicable Customer Name‟s Data Processor, will be

responsible for paying the Communications line charges (for both sent and received data on their side of the ELISE KADOE Service), in line with Schedule 3.

of 105

1.5.6 The ELISE KADOE Service is defined as the boundary between the DVLA IT Supplier, and Customer Name or if applicable Customer Name‟s Data Processor. Monitoring and reporting of the ELISE KADOE Service Levels at the ELISE KADOE Service Boundary will be part of the responsibility of each party.

1.6. MEETINGS 1.6.1 Either Party shall upon the receipt of reasonable notice (from the other

Party) and during normal office hours attend all meetings for the discussion of matters connected with the performance of the Services.

1.6.2 The Parties agree to meet, in person or via video/telephone conference,

annually within 20 Working Days of the anniversary of the Agreement Date to review the Services and the performance of the Contract. Such review to include:

(a) The ongoing need for the Services as defined and any consequential

variation to the terms of the Contract; (b) The performance of the Services; (c) The assurance of the Services and Customer Name handling of any of

the DVLA Data provided under the Contract.

1.7. INSPECTION 1.7.1 During the course of the Contract the DVLA Representative and/or the

Department shall have the power to inspect and examine any premises of Customer Name. In exceptional circumstances in relation to abuse of the service, access to third party Customers premises may be required. Other than in exceptional circumstances, such as a suspected serious breach of data security, examinations will be by prior contact and DVLA will notify Customer Name in advance of any third party premises they wish to examine.

1.7.2 In addition the DVLA Representative and/or the Department shall have the

power to inspect and examine any security measures employed by Customer Name, at any reasonable time, for the purpose of ensuring ongoing compliance with the contract, including but not limited to the security and use of data provided. In exceptional circumstances in relation to compliance of the Contract and the security and use of data provided, access to third party Customers premises may be required.

1.7.3 The right to inspect and examine the utilisation of this Service shall not

apply to the extent that an inspection or examination would jeopardise the confidentiality of information relating to Customer Name‟s other clients except where it is appropriate in the circumstances where Customer Name is acting as an intermediary for its clients in relation to the ELISE KADOE service.

of 105

1.8. PAYMENT 1.8.1 Payment to DVLA shall be made in accordance with the charges as

specifically referred to in Schedule 3 (Charges and Payment). 1.9. CORRUPT GIFTS AND PAYMENTS OF COMMISSION 1.9.1 Both Parties shall not receive or agree to receive from any person, or offer

or agree to give to any person, or procure for any person, any gift or consideration of any kind, as an inducement or reward for doing or not doing anything, or for showing favour or disfavour to any person in relation to the Contract or any other contract with the Crown.

1.9.2 Both Parties shall not conspire with any person to do any of the acts

mentioned in clause 1.9.1. 1.9.3 Any: -

(a) breach by either Party of this clause 1.9 and/ or

(b) commission of any offence by either Party under the Bribery Act 2010 or other relevant or equivalent legislation, or any statutory modification or re-enactment thereof in relation to this or any other contract for the Crown;

shall entitle either Party to terminate the Contract with immediate effect and recover from the other Party the amount of any loss resulting from such termination the amount of value of any such gift, consideration or commission.

1.10. FREEDOM OF INFORMATION AND DISCLOSURE OF INFORMATION 1.10.1 Each Party acknowledges that the other Party is subject to the requirements

of the FOIA and the Environmental Information Regulations 2004 and each Party shall assist and cooperate with the other (at their own expense) to enable the other Party to comply with these Information disclosure obligations.

1.10.2 Where a Party receives a Request for Information in relation to Information

which it is holding on behalf of the other Party, it shall (and shall procure that its sub-contractors shall):-

(a) transfer the Request for Information to the other Party as soon as

practicable after receipt and in any event within [two] Working Days of receiving a Request for Information;

of 105

(b) provide the other Party with a copy of all Information in its possession or power in the form that the other Party requires within [five] Working Days (or as otherwise agreed between the Parties);

(c) provide all necessary assistance as reasonably requested by the other

Party to enable the other Party to respond to a Request for Information within the time for compliance set out in section 10 of the FOIA [or regulation 5 of the Environmental Information Regulations].

1.10.3 Where a Party receives a Request for Information which relates to the

Contract, it shall inform the other Party of the Request for Information as soon as practicable after receipt and in any event within [two] Working Days of receiving a Request for Information.

1.10.4 If either Party determines that Information (including Confidential

Information) must be disclosed pursuant to clause 1.10.3, it shall notify the other Party of that decision at least [two] Working Days before disclosure.

1.10.5 Each Party shall be responsible for determining at its absolute discretion

whether the Commercially Sensitive Information and/or any other Information:-

(a) is exempt from disclosure under the FOIA or the Environmental

Information Regulations;

(b) is to be disclosed in response to a Request for Information. 1.10.6 Each Party acknowledges that the other Party may, acting in accordance

with the Department for Constitutional Affairs‟ Code of Practice on the Discharge of Functions of Public Authorities under Part I of the Freedom of Information Act 2000”, be obliged under the FOIA or the Environmental Information Regulations to disclose Information:-

(a) without consulting with the other Party, or

(b) following consultation with the other Party and having taken its views

into account.

1.10.7 Each Party acknowledges that any lists or schedules provided by it outlining Confidential Information are of indicative value only and that the other Party may nevertheless be obliged to disclose Confidential Information in accordance with clause 1.10.6.

1.10.8 Subject to clauses 1.10.1 to 1.10.7, Customer Name shall not disclose the

Contract or any provision thereof or any information resulting from, in connection with, or during the course of, the Contract, to any person unless it is strictly necessary for the performance of the Contract, and authorised in writing by DVLA. Customer Name shall comply with any instructions regarding changes to authorisations and other instructions regarding

of 105

disclosure or non-disclosure. This clause does not apply in relation to information:

(a) which is in or enters the public domain otherwise than by a breach of

an obligation of confidentiality

(b) which is or becomes known from other sources without breach of any restriction on disclosure or

(c) which is required to be disclosed by law or any professional or

regulatory obligation. 1.10.9 Subject to clause 1.10.8, Customer Name shall ensure that information

about the Contract, or arising from or connected with the Contract: -

(a) is divulged only to the minimum number of persons (b) is divulged only to the extent essential to each person‟s action in

carrying out (or in connection with) the Contract and that such persons do not further divulge such information; and

(c) is properly safeguarded.

1.10.10 Customer Name shall ensure that any contract with: -

(a) any employee of his, or (b) any contractor of his engaged in any way in connection with the

Contract in accordance with clause 1.17,

contains a condition requiring that person to keep all information in relation to the Contract and its performance confidential, and shall be bound by clause 1.10.8 and this clause 1.10.10.

1.10.11 No information regarding the service being provided under the Contract, or

facilities to photograph or film, shall be given or permitted by Customer Name except with the prior written permission of DVLA. Customer Name agrees to refer any press enquiry or similar enquiry to DVLA. This clause does not apply in relation to information:

(a) which is in or enters the public domain otherwise than by a breach of

an obligation of confidentiality

(b) which is or becomes known to Customer Name from other sources without breach of any restriction on disclosure or breach of this Contract or

(c) which is required to be disclosed by law or any professional or regulatory obligation.

of 105

1.10.12 Customer Name shall not, in connection with the Contract, communicate

with representatives of the general or technical press, radio, television or other communications media nor issue nor cause to be issued any press release, public announcement or disclosure of any kind or nature whatsoever or otherwise disclose the existence of the Contract or the service to be provided unless specifically granted permission to do so in advance and in writing by DVLA.

1.10.13 Except with the consent in writing of DVLA Customer Name shall not make

use of the Contract or any information issued or furnished by or on behalf of DVLA otherwise than for the purpose of the Contract.

1.11. DISCRIMINATION

1.11.1 Customer Name shall not unlawfully discriminate either directly or indirectly

or by way of victimisation or harassment against a person on such grounds as race, colour, ethnic or national origin, disability, sex or sexual orientation, religion or belief, or age and without prejudice to the generality of the foregoing Customer Name shall not unlawfully discriminate within the meaning and scope of the Equality Act 2010 or other relevant or equivalent legislation, or any statutory modification or re-enactment thereof.

1.11.2 Customer Name shall take all reasonable steps to secure the observance of

clause 1.11.1 by all Staff. 1.11.3 Customer Name shall comply with the provisions of the Human Rights Act

1998 or other relevant or equivalent legislation, or any statutory modification or re-enactment thereof

1.12. CHANGE OF CONTROL 1.12.1 Customer Name shall notify the DVLA as soon as is practical if Customer

Name undergoes a change of control within the meaning of section 450 of the Corporation Tax Act 2010 (“change of control”). The DVLA may suspend or terminate the Contract by notice in writing with immediate effect within six months of:

(a) being notified that a change of control has occurred and which in the

opinion of the DVLA impacts adversely and materially on the performance of the Contract; or

(b) where no notification has been made, the date that the DVLA

becomes aware of the change of control, but shall not be permitted to suspend or terminate where written consent of the DVLA was granted prior to the change of control.

1.12.2 Customer Name shall inform the DVLA of any change, or proposed change in the name of or status of Customer Name.

of 105

1.12.3 Customer Name shall comply with any reasonable and relevant request by

DVLA for information arising from this clause. 1.13. SUSPENSION OF THE SERVICE 1.13.1 DVLA will carry out an immediate suspension of the Service if there is

shown to be any breach of security. Suspension will remain until DVLA has received assurances that the matter resulting in the suspension has been resolved to the satisfaction of DVLA.

1.14. TERMINATION OF THE CONTRACT 1.14.1 A Party may serve written notice to terminate the Contract for Default on the

other Party if the other Party commits a Default. Such notice shall specify the Default and shall take effect after:

(a) 25 Working Days, or such other longer period as may be specified in

the written notice, where the party deemed to be in default has not remedied the Default to the satisfaction of the other party; or

(b) 90 Working Days where the Default is for non-payment of undisputed

sums of money due and such sums remain outstanding.

1.14.2 On receipt of the written notice the party deemed to be in default shall arrange a meeting between the Parties within 5 Working Days and following that meeting the Contract shall be terminated with immediate effect where the Parties agree that the:

(a) Default is not capable of remedy; or

(b) Default is a material breach of the Contract.

1.15. BREAK 1.15.1 Either party shall in addition to its powers under any other of these clauses

have power to terminate the Contract at any time by giving to the other party three month‟s written notice. Upon the expiry of the notice the Contract shall be terminated without prejudice to the rights of the parties accrued to the date of termination.

1.16. CONSEQUENCES OF TERMINATION AND BREAK 1.16.1 Where the Contract is terminated under clause 1.14 (Termination of the

Contract), or clause 1.15 (Break) any sum due or accruing from Customer Name to DVLA, up to the date of termination will still be payable to DVLA.

1.16.2 Upon the termination of the Contract, Customer Name shall not sell or offer

any goods or Services of any type using data acquired from DVLA under the terms of the Contract.

of 105

1.16.3 Customer Name can retain data held in order to fulfil their obligations.

However, in these circumstances Customer Name is required to confirm in writing to the DVLA Representative that data obtained from DVLA will only be kept for a reasonable period to satisfy business and legislative requirements including compliance with the DPA. However all evidence in respect of enquiries made under this Service should be retained in accordance with clause 1.21 (Retention of Documentation and Audit Access) of this Schedule.

1.17. ASSIGNMENT, SUB-CONTRACTORS AND SUPPLIERS 1.17.1 Customer Name shall not sub-contract or transfer, assign, charge, or

otherwise dispose of the Contract or any part of it without the prior written consent of DVLA.

1.18. LOSS OR DAMAGE 1.18.1 Neither Party excludes or limits liability to the other Party for:

(a) death or personal injury caused by its negligence; or

(b) Fraud; or

(c) fraudulent misrepresentation; or

(d) any breach of any obligations implied by Section 2 of the Supply of Goods and Services Act 1982.

1.18.2 Customer Name shall indemnify the DVLA against all reasonable costs incurred for any Data loss or any Data mis-use (with particular reference to the Data Protection Act) in respect of the DVLA Data to the extent and in accordance with the mitigation actions required. Any request for reasonable costs shall be submitted by the DVLA to Customer Name for consideration, discussion and agreement.

1.18.3 The DVLA shall indemnify Customer Name against all reasonable costs

where the DVLA Data is corrupted or lost or degraded during any collection, processing, storage or transmission by the DVLA or the DVLA personnel of the DVLA Data to the extent and in accordance with the mitigation actions required.

Any request for reasonable costs shall be submitted by Customer Name to the DVLA for consideration, discussion and agreement.

1.18.4 Subject always to clause 1.18.1, in no event shall either Party be liable to

the other for any:

(a) loss of profits, business, revenue or goodwill; and/or

(b) loss of savings (whether anticipated or otherwise); and/or

of 105

(c) indirect or consequential loss or damage.

1.19. DATA PROTECTION 1.19.1 Customer Name will notify the Information Commissioner of the processing

of personal data for inclusion on the Register of Data Controllers. Customer Name must be registered under the sections applicable for the use that the data is being applied for, and will be required to produce proof of such notification at the start of and periodically during the operation of the Contract. Customer Name must, at all times, comply with the terms of the Data Protection Act 1998 including subsequent amendments or legislation of a similar nature.

1.19.2 Customer Name is advised that it is an offence under the Data Protection

Act 1998 for a person, knowingly or recklessly without the consent of the data controller, to obtain or disclose personal data or the information contained in the data or to procure the disclosure to another person the information contained in personal data. It is the DVLA‟s intention to ensure that any breaches of the Data Protection Act are fully investigated and, if appropriate, referred to the Information Commissioner. Any subsequent prosecutions will mean all future requests for information, whether by electronic or manual means, may be refused.

1.19.3 If at any time Customer Name or any senior officer of Customer Name,

being the subject of a complaint to the Information Commissioner, has that complaint upheld by the Commissioner, Customer Name shall inform DVLA Representative.

1.19.4 If any time Customer Name or an employee or official of Customer Name is

subject to an allegation of a Data Protection breach that has the potential to cause embarrassment to DVLA, Customer Name shall inform DVLA Representative.

1.19.5 Customer Name shall ensure that their staff are aware of and comply with

the need to ensure confidentiality and integrity and compliance with the Data Protection Act 1998.

1.20. INSOLVENCY 1.20.1 Customer Name shall inform DVLA: -

of 105

(a) If being an individual, or where Customer Name is a firm, any partner in that firm, shall at any time become bankrupt, or shall have a receiving order or administration order made against him, or shall make any composition or arrangement with or for the benefit of his creditors, or shall make any conveyance or assignment for the benefit of his creditors, or shall purport to do so, or if in Scotland he shall become insolvent or notour bankrupt, or any application shall be made under any bankruptcy Act for the time being in force for sequestration of his estate, or a trust deed shall be granted by him for the benefit of his creditors; or

(b) If being a company, he passes a resolution, or the Court makes an

order, that Customer Name be wound up otherwise than for the purpose of reconstruction or amalgamation, or if a receiver or manager on behalf of a creditor shall be appointed, or if circumstances shall arise which entitle the Court, otherwise than for the purposes of amalgamation or reconstruction, to make a winding-up order.

1.20.2 If any of the events in the clauses 1.20.1(a) or 1.20.1(b) occur (whether or

not Customer Name has informed DVLA) DVLA may at any time by notice in writing summarily terminate the Contract without compensation to Customer Name. Such termination shall not prejudice or affect any right of action or remedy, which shall have accrued before that date or shall accrue thereafter to DVLA.

1.21. RETENTION OF DOCUMENTATION AND AUDIT ACCESS 1.21.1 Customer Name shall retain for a minimum period of 2 years from the date

of conclusion or longer period as may be agreed between DVLA and Customer Name (such agreement to be recorded in writing), full and accurate records of the performance of the Service, including records of all payments made to DVLA by Customer Name in relation to the Contract.

1.21.2 Customer Name shall:

(a) produce such records retained pursuant to clause 1.21.1 as DVLA may reasonably require. This may include, but not limited to, any mis-matched or incorrect KADOE request files that have been submitted in pursuance of the business objective. These will be cross-referenced to the correct record, KADOE request file or issue that gave arise to the incorrect request submission. This will enable DVLA to establish the reason for the submission. The vehicle keeper details obtained in error under such circumstances must be deleted;

(b) afford such facilities as DVLA may reasonably require for his representatives to inspect the records retained pursuant to clause 1.21.1. The right granted by this clause 1.21.2(b) shall not apply to the extent that the confidentiality of information relating to Customer Name‟s other clients would be jeopardised by such inspection; and

of 105

(c) provide such explanations of records produced pursuant to clause 1.21.3(a) or inspected pursuant to clause1.21.3(b) as DVLA may reasonably require.

1.21.3 For the purpose of:

(a) the examination and certification of DVLA‟s accounts; or

(b) any examination pursuant to section 6 (1) of the National Audit Act1983 of the economy, efficiency and effectiveness with which DVLA has used its resources;

the Comptroller and Auditor General shall have a right of access at all reasonable times to such documents as he may require which are owned, held or otherwise within the control of Customer Name and Customer Name shall provide to the Comptroller and Auditor General such assistance and such oral and/or written information and explanation as he may require.

1.21.4 For the avoidance of doubt, nothing in clause 1.21.1, clause 1.21.2 or

clause1.21.3 constitutes a requirement or agreement for the purposes of section 6(3) (d) of the National Audit Act 1983 for the examination, certification or inspection of the accounts of Customer Name.

1.22. SERVING OF NOTICES 1.22.1 Any Notice required to be given or served under the Contract by the either

party shall be in writing and shall be served by either: -

(a) delivery by hand to either Customer Name‟s Representative or the DVLA Representative, or

(b) sending it by first-class post to either party‟s last known place of

business or registered office, when it shall be deemed to be served on the day when in the ordinary course of the post it would have been delivered.

1.23. DISPUTE RESOLUTION 1.23.1 The Parties shall attempt in good faith to negotiate a settlement to any

dispute between them arising out of or in connection with the Contract within 20 Working Days of either Party notifying the other of the dispute and such efforts shall involve the escalation of the dispute to those people nominated in Annex A.

1.23.2 Nothing in this dispute resolution procedure shall prevent the Parties from

seeking from any court of competent jurisdiction an interim order restraining the other Party from doing any act or compelling the other Party to do any act.

of 105

1.23.3 If the dispute cannot be resolved by the Parties pursuant to clause 1.23.1 the Parties shall refer it to mediation pursuant to the procedure set out in clause 1.23.5 unless the other Party considers that the dispute is not suitable for resolution by mediation.

1.23.4 The obligations of the Parties under the Contract shall not cease, or be

suspended or delayed by the reference of a dispute to mediation (or arbitration) and both Parties and their Staff shall comply fully with the requirements of the Contract at all times.

1.23.5 The procedure for mediation and consequential provisions relating to

mediation are as follows:

(a) a mediator (the “Mediator”) shall be chosen by agreement between the Parties or, if they are unable to agree upon a Mediator within 10 Working Days after a request by one Party to the other or if the Mediator agreed upon is unable or unwilling to act, either Party shall within 10 Working Days from the date of the proposal to appoint a Mediator or within 10 Working Days of notice to either Party that he is unable or unwilling to act, apply to the Centre for Effective Dispute Resolution or other mediation provider to appoint a Mediator.

(b) The Parties shall within 10 Working Days of the appointment of the

Mediator meet with him in order to agree a programme for the exchange of all relevant information and the structure to be adopted for negotiations to be held. If considered appropriate, the Parties may at any stage seek assistance from the Centre for Effective Dispute Resolution or other mediation provider to provide guidance on a suitable procedure.

(c) Unless otherwise agreed, all negotiations connected with the dispute

and any settlement agreement relating to it shall be conducted in confidence and without prejudice to the rights of the Parties in any future proceedings.

(d) If the Parties reach agreement on the resolution of the dispute, the

agreement shall be recorded in writing and shall be binding on the Parties once it is signed by their duly authorised representatives.

(e) Failing agreement, either of the Parties may invite the Mediator to

provide a non-binding but informative written opinion. Such an opinion shall be provided on a without prejudice basis and shall not be used in evidence in any proceedings relating to the Contract without the prior written consent of both Parties.

(f) If the Parties fail to reach agreement in the structured negotiations

within 60 Working Days of the Mediator being appointed, or such longer period as may be agreed by the Parties, then any dispute or difference between them may be referred to the Courts. Unless the

of 105

dispute is referred to arbitration pursuant to the procedures set out in clause 1.23.6.

1.23.6 Subject to clause 1.23.2, the Parties shall not institute court proceedings

until the procedures set out in clauses 1.23.1 and 1.23.3 have been completed save that:

(a) either Party may at any time before court proceedings are

commenced, serve a notice on the other Party requiring the dispute to be referred to and resolved by arbitration in accordance with clause 1.23.7.

(b) if either Party intends to commence court proceedings, it shall serve

written notice on the other Party of its intentions to do so giving 21 days to reply, requiring the dispute to be referred to and resolved by arbitration in accordance with 1.23.7.

1.23.7 In the event that any arbitration proceedings are commenced pursuant to

clause 1.23.6:

(a) the arbitration shall be governed by the provisions of the Arbitration Act 1996;

(b) either Party shall give a written notice of arbitration to the other Party

(the “Arbitration Notice”) stating:

(i) that the dispute is referred to arbitration; and

(ii) providing details of the issues to be resolved; (c) the London Court of International Arbitration (“LCIA”) procedural rules

in force at the date that the dispute was referred to arbitration in accordance with 1.23.7 (b) shall be applied and are deemed to be incorporated by reference to the Contract and the decision of the arbitrator shall be binding on the Parties in the absence of any material failure to comply with such rules;

(d) the tribunal shall consist of a sole arbitrator to be agreed by the

Parties; (e) if the Parties fail to agree the appointment of the arbitrator within 10

days of the Arbitration Notice being issued by either Party under clause 1.23.7 (b) or if the person appointed is unable or unwilling to act, the arbitrator shall be appointed by the LCIA;

(f) the arbitration proceedings shall take place in London and in the

English language; and (g) the arbitration proceedings shall be governed by, and interpreted in

accordance with, English law.

of 105

1.24. SEVERABILITY 1.24.1 If any provision of the Contract is held invalid, illegal or unenforceable for

any reason by any court of competent jurisdiction, such provision shall be severed and the remainder of the provisions of the Contract shall continue in full force and effect as if the Contract had been executed with the invalid, illegal or unenforceable provision eliminated. In the event of a holding of invalidity so fundamental as to prevent the accomplishment of the purpose of the Contract, DVLA and Customer Name shall immediately commence negotiations in good faith to remedy the invalidity.

1.25. TRANSFER OF RESPONSIBILITY 1.25.1 In the event that a different organisation is required by DVLA to take over

provision of the IT Services at the expiry or termination of the Contract, Customer Name shall co-operate in the transfer, under arrangements to be notified to him by DVLA.

1.25.2 The transfer pursuant to clause 1.25.1 above shall be arranged between the

Department and Customer Name so as to reduce to a minimum any interruption in the Services.

1.26. WAIVER 1.26.1 The failure of DVLA or Customer Name to exercise any right or remedy

shall not constitute a waiver of that right or remedy. 1.26.2 No waiver shall be effective unless it is communicated to either DVLA or

Customer Name in writing. 1.26.3 A waiver of any right or remedy arising from a breach of contract shall not

constitute a waiver of any right or remedy arising from any other breach of the Contract.

1.27. RIGHTS OF THIRD PARTIES

1.27.1 Nothing in the Contract confers or purports to confer on any third party any

right to enforce any term of the Contract.

of 105

1.28. FORCE MAJEURE 1.28.1 If, by any reason of any matter outside of DVLA‟s reasonable control,

including but not limited to acts of nature, war, hostilities, strikes, lock-outs, or of any fire at any of DVLA‟s premises or those of his suppliers or any act or default of Customer Name, DVLA shall have been delayed in completing all or part of the Services. DVLA shall, upon becoming aware that any such delay has been caused, give to Customer Name, notice in writing of his claim for an extension of time for the completion of the Services and Customer Name shall allow DVLA an extension of time for such completion in respect of any delay caused by any of the circumstances before mentioned as shall be reasonable.

1.29. CONFLICT OF INTEREST 1.29.1 It shall be Customer Name‟s responsibility to ensure that no conflict of

interest arises in connection with the Services to be provided by DVLA or any provision under the Contract. DVLA will be given notice by Customer Name immediately on discovery of any such potential or actual conflict of interest and Customer Name will immediately cease any act or omission by Customer Name, which causes such potential or actual conflict.

1.30. INTELLECTUAL PROPERTY RIGHTS 1.30.1 The Contract and any publications or data relating to the contract are

subject to Crown Copyright regulations. 1.30.2 Ownership of the Results

(a) Subject to any prior rights of DVLA, and to the rights of third parties or of Customer Name arising otherwise than under the Contract. All copyright and rights in the nature of Copyright, unregistered design rights, registered design rights, patent rights and all other rights of a like nature resulting from the Services, shall vest in and be the absolute property of DVLA.

(b) Nothing in the Contract shall in any way derogate from the rights of

DVLA under any legislation relating to patents, copyrights, registered design rights or design rights.

1.30.3 Copyright and Publication

(a) Under delegated powers of Crown Copyright, DVLA shall be the proprietor of the copyright in respect of the Contract and any data or publications relating to this copyright.

(b) Customer Name shall provide any reports suitable for publication,

monitoring and liaison meetings.

of 105

(c) All reports prepared for publication, under the Contract shall carry the disclaimer and copyright statement below.

The disclaimer shall be:

“The authors of this report are employed by Customer Name. The work reported herein was carried out under a contract placed on [commencement date of contract] by the Driver and Vehicle Licensing Agency. Any views expressed are not necessarily those of DVLA.”

1.31. CHANGE CONTROL PROCEDURES 1.31.1 No changes will be made to the Services unless agreed by the DVLA and

Customer Name in writing in accordance with Schedule 4. 1.32. USE OF BRANDS, LOGOS AND TRADE MARKS 1.32.1 DVLA does not grant Customer Name licence to use any of its brands,

logos or trademarks except for use on communications or official contract documents that is exchanged between DVLA and Customer Name as part of the fulfilment of the Contract. Any further specific uses (including promotional purposes) of DVLA brand, logos or trademarks that are necessary in order to fulfil the Contract must be agreed in writing by DVLA in advance.

1.32.2 While DVLA may permit Customer Name to make known, for promotional

purposes, the fact that the Services in the Contract are provided by DVLA, Customer Name will not be entitled to use any of DVLA‟s brands, logos or Trade Marks for such promotional purposes, unless by written agreement.

1.32.3 Customer Name shall not adopt or use any trade mark, symbol or device

which incorporates or is confusingly similar to, or is a simulation or colourable imitation of, DVLA‟s brands, logos or Trade Marks, or unfairly competes with the same. Customer Name shall not during the operation of the Contract, apply anywhere in the world to register, any DVLA brand, logo or Trade Marks identical to or so nearly resembling the same as to be likely to deceive or cause confusion.

1.32.4 Furthermore, Customer Name agrees not to misrepresent their relationship

with DVLA. Customer Name is free to contact the DVLA Representative for advice on how this relationship should be represented in marketing / promotional material.

1.32.5 DVLA will expect Customer Name to take responsibility for the content of

their own website and literature, and maintain accurate information and any references to DVLA.

1.32.6 If there are any links titled „DVLA‟ or „Driver and Vehicle Licensing Agency‟,

they must not connect to pages within your website but should link to the

of 105

DVLA website and ideally the relevant page for the subject matter being addressed.

1.33. USE OF DVLA’s NAME

1.33.1 Customer Name may make reference to the fact that DVLA supplies the

data that supports their product(s). However, the nature of the relationship should not be embellished beyond a simple customer/supplier relationship, explicitly or otherwise. Customer Name must not misrepresent their relationship with the DVLA.

1.33.2 It should not be implied that Customer Name has a direct link to the DVLA

database where no such link exists. 1.33.3 In the course of trade, the name “DVLA” may be used in the following ways,

provided it is not obviously intended to mislead in anyway:

(a) descriptive use – where used in conjunction with products or Services supplied by DVLA, e.g. DVLA Keeper at Date of Event Service data, DVLA sourced data etc;

(b) use denoting origin – e.g. DVLA sourced data;

(c) (Customer Name) - is “recognised by DVLA as a provider of data”;

(d) giving of geographical information – e.g. DVLA located in Swansea;

(e) indicating regulations and laws – e.g. DVLA rules for the release of Vehicle Licence Data;

(f) disassociation from other entities – e.g. “you are not purchasing data directly from the DVLA”.

1.33.4 Under the guidelines, the following types of use of „DVLA‟ by data providers

will not be allowed:

(a) anything that would lead customers to believe that they are dealing with DVLA or any part of it;

(b) „DVLA‟ being in any part of the domain name or extended URL;

(c) use of DVLA in the HTML meta title either as a standalone word or in

any phrase;

(d) use of „DVLA‟ in the HTML meta description as a standalone word or in any phrase;

(e) use of „DVLA‟ as an HTML keyword as a standalone word;

of 105

(f) use of „DVLA‟ as a standalone word i.e. not in a phrase, as in a pay-per-click search term;

(g) appearance of „DVLA‟ on any one web page more than 7 times excluding the disclaimer.

1.33.5 This clause 1.33 will apply to all use of “DVLA” in electronic or physical

media whether used in hidden or visible text. 1.33.6 Customer Name will be expected to ensure that their compliance with these

clauses 1.32 and 1.33 is maintained. In addition, DVLA will monitor Customer Name‟s sites to ensure that these clauses are not misused in any way. Failure to do so may result in legal action being taken.

of 105

SCHEDULE 1

DEFINITIONS AND INTERPRETATIONS

of 105

DEFINITIONS AND INTERPRETATIONS In the Contract, unless the context requires otherwise, the following words and phrases shall have the following meanings: - “Authorised organisations” means organisations that are authorised by DVLA to enquire on vehicle keeper data. “Charges” means the charges payable to DVLA by Customer Name, more specifically detailed in Schedule 3. “Commencement Date” means the agreed commencement date of the Contract between DVLA and Customer Name. “Code of Connection” is part of the governance and assurance the DVLA has in place to ensure data handling meets minimum acceptable standards. The Code of Connection gives the DVLA assurance that connecting organisations have implemented best practice information assurance standards. The DVLA has a responsibility to ensure the data it is responsible for is handled appropriately by data partners and customers. “Contract” means this written agreement between DVLA and Customer Name consisting of all schedules and any attached Appendices and Annexes. “Contract Change” means any change to the Contract. “Crown” means the government of the United Kingdom (including the Northern Ireland Executive Committee and Northern Ireland Departments, the Scottish Executive and the National Assembly for Wales), including, but not limited to, government ministers, government departments, government and particular bodies and government agencies. “Customers‟ Representative” means a competent person appointed by Customer Name to be his representative in relation to the performance of the Contract who will receive and act on any directions given by the DVLA Representative. “Data” means the Vehicle Keeper Data that is to be provided to Customer Name more particularly described in Schedule 2. “Data Controller” means a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed. “Data loss” means any instance where the DVLA Data has been lost, misplaced or destroyed, where unauthorised persons have gained or been allowed access to the DVLA Data, or where, due to the breakdown of, or failure to comply with protective security policies or measures including technical and procedural measures, there is a potential that unintended or unauthorised access to the DVLA Data may be possible.

of 105

“Data mis-use” means any use of the DVLA Data, which is not in accordance with the Schedule 2 “Data Processor” means any person or company (other than an employee of the data controller) who processes the data on behalf of the data controller. Data Processors facilitate the transfer of data but do not, and are not permitted, to access or use DVLA data for their own purposes. “Days” shall mean calendar days save where the context otherwise requires. “Default” means any breach of the obligations of the relevant Party (including but not limited to fundamental breach or breach of a fundamental term) or any other default, act, omission, negligence or negligent statement of the relevant Party or the Staff in connection with or in relation to the subject-matter of the Contract and in respect of which such Party is liable to the other. “Department” means the department of the Secretary of State for Transport‟s department. “DVLA” means the Driver and Vehicle Licensing Agency acting on behalf of the Secretary of State for Transport. “DVLA Representative” means a competent person appointed by the DVLA to be his representative in relation to the performance of the Contract. “Fraud” means any offence under Laws creating offences in respect of fraudulent acts or at common law in respect of fraudulent acts in relation to the Contract or defrauding or attempting to defraud or conspiring to defraud the Crown.

“ELISE” means Electronic Links Implementation and Strategic Enablement. The ELISE business to business (B2B) strategy delivers a set of electronic message based services for all high volume B2B transactions and is housed in a secure environment that adheres to the e-Government Information Framework (eGIF) standards. “Evidence” means Customer Name‟s proof that the enquiry is appropriate. “Intermediary” means (in the context of the ELISE KADOE Service), any organisation who submits, receives and/or processes vehicle keeper enquiries and data on behalf of another organisation. “IT Supplier” means the organisation contracted during the period of validity of the Contract for the provision of computer facilities to enable DVLA to discharge its vehicle keeper data. “KADOE Service” means Keeper at Date of Event Service. This describes the electronic service where the Vehicle keepers name and address details are supplied for a specific date of event.

of 105

“Mediator” means a person who conducts mediation between two parties, with their consent, for the purpose of assisting them in settling their dispute. “Month” means calendar month, unless otherwise defined. “Notice” means the information given of some act done or required to be done. “Permitted Purpose” means a specific purpose for access to vehicle keeper data that has been authorised by DVLA. “Person” - any reference to a “person” shall, as the context may require, be construed as a reference to any individual, firm, company, corporation, Government Department, Agency or any association or partnership (whether or not having a separate legal personality). “Records” or “Records or parts there of” means the information that is obtained from DVLA‟s Vehicle database as the result of a successful enquiry. “Results” shall mean any document, item, product, material or other work produced for the purposes of the provision of the Service or in connection with the service by DVLA. This shall include any idea, invention, innovation and design. “Service(s)” means all Services detailed in Schedule 2 of the Contract. “Service Provider” means any organisation which acts as a Data Processor or Intermediary as defined in the Contract. “VAT” means value added tax in accordance with the provisions of the Value Added Tax Act 1994. “Working Day” means a day (other than a Saturday or Sunday) on which banks are open for general business in the City of London. Unless the context requires otherwise, the singular shall include the plural and vice versa, and words expressed in any gender shall include any other gender. The headings are inserted for convenience only and shall not affect the interpretation of the Contract. Reference to any legislative requirement or similar instrument shall be deemed to include reference to any subsequent amendment to them.

of 105

SCHEDULE 2

SERVICE DESCRIPTION

of 105

2.1. PURPOSE 2.1.1 This schedule sets out the details of the data service that the Contract

relates to.

2.2. DETAILS OF PROVISION 2.2.1 DVLA will make the Non Fee Paying KADOE Service available to Customer

Name. In return, Customer Name will provide payment as specified in Schedule 3.

2.2.2 The KADOE Service provides access to Data relating to vehicles where the address of the registered vehicle keeper is (at the date of event) in Great Britain.

2.2.3 The DVLA shall notify Customer Name if in the future the Non Fee Paying KADOE Service also provides access to Data relating to vehicles where the address of the registered vehicle keeper (at the date of event) is in Northern Ireland.

2.2.4 The Non Fee Paying KADOE Service does not provide access to Data from vehicle keeper records that are marked as unavailable for release through any electronic channel. Particular records may be marked in this way because of the keeper‟s personal or domestic reasons, where DVLA casework or an investigation is ongoing.

2.3. BACKGROUND

2.3.1 Regulation 27 of the Road Vehicles (Registration and Licensing) Regulations 2002, as amended, provides that the Secretary of State may make particulars contained in the vehicle register available to authorised organisations for any purpose connected with the investigation of an offence, or a decriminalised parking contravention.

2.3.2 Section 194 of the Transport Act 2000 provides that: “Information obtained by-

a) any Minister of the Crown or government department

may be disclosed to the charging authority or any of the charging authorities, in relation to a charging scheme, under this Part for or in connection with the exercise of any of their functions with respect to the charging scheme”

2.3.3 This power is discretionary. No Customer has the right to obtain the Data;

Customer Name also must adhere to the principles of the Data Protection Act 1998 when such information is released.

2.3.4 Any Customer wishing to be included in this scheme will be bound by the

terms of the Contract.

of 105

2.4. DEMONSTRABLE BUSINESS NEED 2.4.1 Applications to join the ELISE KADOE service will only be considered for

organisations that have a demonstrable business need, which has been approved by DVLA for access to this Service, more specifically referred to in Appendix A.

2.4.2 Once a contract is in place for the ELISE KADOE Service, Customer Name

must notify DVLA of any proposed changes to their business need including the introduction of any new clients (where Customer Name is acting as an „intermediary‟ or service provider to a third party). Any proposed changes must be agreed with DVLA prior to any requests being submitted in accordance with clause 1.31.1 and Schedule 4.

2.5. ACTUAL DATA NEED

2.5.1 The specific vehicle keeper data that is required by Customer Name will be

defined according to their demonstrable business need, their business processes, and also the permitted purposes as agreed by DVLA for the granting and supply of that information, more specifically referred to in Appendix A.

2.5.2 No data other than what is required to meet the business need will be

provided to Customer Name. Only the least amount of data will be displayed in response to each enquiry. DVLA reserve the right to change the data items within each category or change the scope if additional categories are needed.

2.5.3 Once a contract is in place for the ELISE KADOE Service, Customer Name

must notify DVLA of any proposed changes to their permitted purposes. Any proposed changes must be agreed with DVLA prior to any requests being submitted in accordance with clause 1.31.1 and Schedule 4.

2.6. INTERNAL COMPLIANCE REGIME

Customer Name will be required to provide a level of assurance to satisfy the DVLA that their existing internal regime is sufficiently robust in relation to:

Business processes and nature of interactions with customers;

Recording of customer interactions and transactions;

Existing audit procedures on business activities and financial reporting,

Staff vetting and hiring procedures;

Named director or senior person within the organisation with responsibility for audit and business process rigour.

of 105

2.7. QUALITY OF RECORDS

2.7.1 DVLA will use reasonable care and skill in the compilation of records, and that the information is delivered in a timely manner.

2.7.2 As data held on DVLA‟s records is supplied in circumstances which, in the

vast majority of cases, are completely outside its control, DVLA does not warrant the accuracy of the records provided. The Agency does not accept liability for any inaccurate information supplied to it by the vehicle keeper or any other source beyond its control.

2.7.3 DVLA shall not be liable to Customer Name, its servants, agents or

principals for any claim for loss or damage, however caused, through possible inaccuracies in the records supplied.

2.8. INPUT/OUTPUT DATA 2.8.1 Prior to submitting and receiving data, Customer Name will need to:

a)

have connectivity to the Vodafone MPLS network;

be signed up for the ELISE Closed User Group;

sign the Code of Connection;

deploy an ftp server and client that utilises Open SSH; and

perform basic testing with DVLA;

have completed and satisfied the exit criteria for End to End Connected testing and User Acceptance testing;

or

b) register with a service provider which will manage the transmission of

enquiries from Customer Name to DVLA via the ELISE link. 2.8.2 A number of Vehicle Keeper records have specific markers on them, which

prevents the release of the data via any electronic channel. Reasons for this include, but are not limited to:

Personal / domestic reasons (to the data subject);

DVLA casework / investigation activity being undertaken (on a one-off or ongoing basis).

2.8.3 Where there is a match based on the Vehicle Registration Mark (VRM) but

markers are present and no information is returned, a letter or “VQ5” (the paper Reply to Non Fee Paying Enquiry) will be despatched directly to the enquiring organisation in relation to the enquiry. In these cases the letter and/or VQ5 must be treated and stored in a secure manner in line with Appendix C.

2.8.4 Prior to acting on the data that is supplied by the Service, Customer Name

must conduct a validation process to ensure that the vehicle data that is

of 105

supplied by the Service matches the vehicle details (e.g. make, model, etc) that are captured on Customer Name‟s case file.

2.8.5 Any records passed to Customer Name from DVLA that do not match the

details that are captured on Customer Name‟s case file must be disregarded, and deleted from any systems. However, records of any enquiries made in error must be kept in line with clause 1.21.2 of the Contract.

2.9. CONDITIONS OF USE 2.9.1 During the operation of the Contract, Customer Name shall use the Data

detailed in the Contract in accordance with the terms of the Contract. 2.9.2 Customer Name will only make enquiries on those vehicles for which they

have permitted purpose to do so as determined by DVLA, more specifically referred to in Appendix A.

2.9.3 Upon receiving vehicle keeper data in response to a KADOE enquiry,

Customer Name will only use that data for the original purpose for which the data was requested, and must not re-use the data obtained for any other event or purpose.

2.9.4 Customer Name will inform DVLA of any proposed changes or additions to

their agreed permitted purposes for which they request vehicle keeper data. No enquiries can be submitted for additional purposes without formal approval by DVLA and this being added to the permitted purposes in Appendix A of the Contract, by way of a variation in accordance with clause 1.31.1 and Schedule 4.

2.9.5 Customer Name shall not transfer, sell or in any way make data available to

any third parties unconnected with the original purpose of the enquiry. 2.9.6 Customer Name will inform DVLA of any changes to their business

processes, which may impact how the ELISE KADOE Service is used. 2.9.7 Customer Name will maintain an electronic audit trail of all enquiries made

and request files submitted. DVLA will also maintain an electronic audit trail of all enquiries made and files submitted by Customer Name, on DVLA systems.

2.9.8 Customer Name shall provide any information reasonably requested by

DVLA within requested deadlines with respect to the use made of records. 2.9.9 Access to Customer Name‟s systems in relation to ELISE KADOE must be

protected by unique user credentials for each employee who has access to the ELISE KADOE system. This means unique User IDs and passwords in line with industry best practice. User IDs will not be shared between employees of Customer Name. Each enquiry will be traceable to a named individual enquirer within Customer Name‟s records.

of 105

2.9.10 Any person who, where duly authorised to do so, acts an agent on behalf of

Customer Name will be held liable under these terms as if he were Customer Name. Arrangements with agents must be acceptable to DVLA and must be agreed in writing, prior to the commencement of any such agreement.

2.9.11 Without prejudice to the Contract Customer Name must research, identify

and notify DVLA without delay of the existence of any situation or envisaged development that will influence the ability of Customer Name to purchase or use the Data over the operation of the Contract.

2.9.12 Without prejudice to the Contract, Customer Name must notify DVLA

without delay of the existence of any situation or envisaged development which could result in publicity or media attention to Customer Name which could adversely reflect on DVLA or the KADOE service.

2.9.13 Any intended publicity implying the DVLA has a connection with any service

provided by Customer Name should be referred to DVLA for approval before issue.

2.9.14 Customer Name shall comply with all statutory provisions, legislation and

other legal requirements affecting the Service and persons employed in relation to the use of this Service.

2.9.15 Customer Name shall at the commencement of the Contract, institute and

maintain throughout the operation of the Contract a properly documented system of quality control to ensure that Data integrity is maintained, which should be approved by Customer Name‟s senior management.

2.9.16 Customer Name shall make available a list of any individuals named as key

personnel who have direct responsibilities for the execution of all or part of the Contract. DVLA may at any time check the electronic trail relating to any activity made by Customer Name, and contact the key person as deemed appropriate. Customer Name is required to inform DVLA Representative of any changes in the key personnel, contact points, addresses, email addresses and telephone numbers, Please refer to Annex B.

2.9.17 Customer Name must inform DVLA of any changes to the operational or

organisational structure of Customer Name which affects the destination of where the data is to be sent (for example, a merger or move of location);

2.9.18 Customer Name shall at all times during the operation of the Contract allow

DVLA Representative and such persons as may from time to time be nominated by DVLA Representative access to:

(a) all locations of or under the control of Customer Name for the purpose

of inspecting any Products derived from the provisions of the ELISE KADOE Service;

of 105

(b) all locations of or under the control of Customer Name for the purpose

of inspecting records and documents in the possession of Customer Name in connection with the provision of the ELISE KADOE Service;

(c) in exceptional circumstances any employee or agent of Customer

Name for the purpose of interviewing him/her/them in connection with any part of the ELISE KADOE Service;

(d) equipment used or proposed to be used in connection with the Data

for the purpose of ensuring that such equipment maintains the integrity of the Electronic Interface Specification and complies with relevant statutory requirements.

2.9.19 Customer Name must ensure that they have sufficient technical knowledge

and expertise in order to understand, implement and support the service. This must include technical resource capable of setting up, managing and problem solving around key technologies of SFTP (Secure File Transfer Protocol) and networking. In particular, firewall configuration and network address translation.

2.10. ADDITIONAL CONDITIONS OF USE FOR INTERMEDIARY

COMPANIES 2.10.1 Where Customer Name is acting as an Intermediary for third party

customers, they must:

a) apply to DVLA in writing of the introduction of any new customers and obtain written authorisation from DVLA. The notification shall include written confirmation from the third party setting out, in such a manner as shall satisfy DVLA, that the reasons for requesting the data are valid;

b) ensure that there are contracts in place with their customers which

ensure that all the terms, clauses, permitted purposes and principles surrounding security and transfer of data within the Contract with DVLA are upheld (please refer to Annex C). Details of such contracts must be provided to DVLA upon request;

c) obtain the relevant codes from DVLA once an appropriate contract is

in place between Customer Name and the third party customer. The charge to add and configure new customers is outlined in Schedule 3;

d) Customer Name will ensure that their third party customers only make

enquiries on those vehicles for which they have permitted purpose to do so as determined by DVLA;

e) Customer Name will inform DVLA of any proposed changes or

additions to their third party customers agreed permitted purposes for which they request vehicle keeper data. No enquiries can be

of 105

submitted for additional purposes without formal written approval by DVLA;

f) shall inform DVLA of any changes to their third party customer details,

to include contact points, addresses, email addresses and telephone numbers;

g) notify DVLA in writing of the proposed introduction of any new types of

customers. Any proposed changes must be agreed by DVLA prior to any requests being submitted on behalf of these new customer types;

h) inform DVLA of any changes to the operational or organisational

structure of their customers which affects the destination of where the data is to be sent (for example, a merger of Local Authorities, or a customer moving location);

i) ensure that each enquiry is at least traceable to an end user

organisation;

j) notify DVLA in writing of any existing or proposed supplier or contractor arrangement that is or will be in place with Customer Name‟s third party customers in order to make vehicle keeper data requests. No enquiries can be submitted via the supplier or contractor until written authorisation has been received from DVLA;

k) inform DVLA of any customer which terminates their contract with

Customer Name;

l) audit their approved list of third party customers at least once during a rolling three year programme (more specifically referred to in Appendix D), and notify DVLA of any changes or issues. Evidence of the audit must be made available to DVLA upon request;

m) be responsible for any charges (described in Schedule 3) relating to

the reconnection or audit visit/revisit carried out by DVLA following a suspension of any of Customer Name‟s third party customers. Customer Name retains the right to recoup these charges from Customer Name‟s third party customers.

2.11. SECURITY REQUIREMENTS 2.11.1 The data sent to Customer Name by DVLA shall not be used for any

purpose other than that defined, to include:

The data shall not be transferred or exchanged in any form, in whole or in substantial part, to any other party (outside of the remit of Customer Name) to include any subsidiaries and associate companies of Customer Name unless such agreement is expressly obtained from the DVLA Representative;

of 105

The data shall not be used to update that information held by Customer Name or its subsidiary and/or associate companies;

2.11.2 Customer Name shall maintain the integrity and confidentiality of the data

sent by DVLA, and shall ensure that the data is only transferred to the originator of the enquiry.

2.11.3 The mechanism of the connection between DVLA and Customer Name is

covered by the Code of Connection. This shall ensure the confidentiality and integrity of the data passed and is subject to formal approval by DVLA IT Security prior to connectivity being established. Such approval will only be granted when the full technical/security features of the connection are defined.

2.11.4 The operation of the connection between Customer Name and DVLA is

subject to the continuous maintenance of the security of the connection. 2.11.5 Customer Name shall ensure that their staff are aware of and comply with

the need to ensure confidentiality and integrity and compliance with the Data Protection Act 1998 (DPA) and any subsequent legislation and Data Protection laws relating to the information and Data sent by DVLA.

2.11.6 Customer Name shall ensure that the data sent by DVLA can only be

accessed by persons / systems that are authorised and necessary to meet the business and technical requirements. Intermediaries or service providers will ensure that once the data is transferred to their third party customers with „permitted purposes‟ as determined by DVLA, the original data is securely destroyed apart from the audit trail.

2.11.7 Customer Name should note that removable media is not permitted in the

delivery of the Contract. Where there is a requirement for Customer Name‟s staff to take data off site in electronic format, the DVLA will consider if it is appropriate to supply an encrypted hard drive.

2.11.8 Any subsequent use of data supplied to you by DVLA must be stored and

utilised in accordance with the Cabinet Office Data Handling Review (June 2008) and subsequent modifications.

Failure to adhere to this guidance or higher standard on the transfer of

data will be regarded as non-compliance with the requirements of the contract.

Personal Information

2.11.9 As a Central Government Agency, the DVLA is obliged to comply with the Mandatory Minimum Measures as set out in the Data Handling Review. This covers the entire information lifecycle including use and access under any commercial agreements and, therefore, it‟s necessary for DVLA to mandate the adherence to these to Customer Name.

of 105

2.11.10 The guidance within the Data Handling Review stipulates that any source of information relating to 1,000 or more individuals will be deemed to be Protected Personal Data. As such, it must be safeguarded in accordance with the Mandatory Minimum Measures as summarised at Appendix E.

Offshoring

2.11.11 Any offshoring of the DVLA Data and offshore access to any of the DVLA

Data shall be subject to the requirements specified in Appendix F. 2.11.12 Unless agreed in writing, none of the DVLA Data should be stored,

processed or accessed outside of the UK and no access to Customer Name‟s systems that hold the DVLA Data should be provided to any commercial organisation outside of the UK.

Non Compliance 2.11.13 Where the DVLA consider there to be a breach of these requirements of

use we reserve the right to suspend the service offering until appropriate evidence is provided to allay concerns.

2.11.14 Where Customer Name is acting as an intermediary or a third party service

provider and has a requirement to onward transmit data, and this onward transmission has been agreed by DVLA Representative, Customer Name must ensure that the onward transmission is carried out in accordance with the DPA, giving due consideration to the volume and sensitivity of the data.

2.11.15 Customer Name shall report any breach of security immediately to DVLA

Representative (contact details as shown in Annex A). 2.11.16 Data must not be transferred outside of the UK without DVLA‟s prior

knowledge and approval. Please refer to Off-shoring Guidance in Appendix F.

2.12. DISTRIBUTION OF RECORDS 2.12.1 Distribution of records is carried out under contract by DVLA‟s IT Supplier.

DVLA does not undertake to provide records except in a form that is compatible with the system capabilities of its IT Supplier. For the avoidance of doubt it will be the responsibility of Customer Name to ensure that the method of record provision by DVLA‟s IT Supplier is suitable and satisfactory to meet Customer Name‟s needs.

2.13. STORAGE OF RECORDS

2.13.1 Customer Name shall hold the Data on one database only. Customer

Name will not copy the Data or link it to any other database without written approval of the DVLA Representative.

of 105

2.13.2 All records containing personal information, including a hard copy of the record (VQ5), screen prints, reports or other data which have been supplied or derived from DVLA‟s system in any format will be retained by Customer Name in a secure manner. Customer Name will retain responsibility for the storage of data and any subsequent failure to do so could result in the suspension of the ELISE KADOE Service in accordance with clause 1.13.

2.13.3 VQ5‟s and screen prints must be stored in a locked cupboard or similar in a

lockable room with a suitable keypad or lock, which must be secured overnight. The VQ5‟s and screen prints should, where possible, be stored onsite. If they are not to be stored onsite, the exact location must be made known to the DVLA in a timely manner.

2.14. AUDIT AND ASSURANCE 2.14.1 Customer Name will be required to self-police their use of the Service, as

set out in the Contract, more specifically referred to in Appendix D. However, DVLA reserves the right to conduct an audit of the systems and processes used by Customer Name to ensure that adequate security practices are being maintained.

2.14.2 DVLA audits will usually be by prior appointment, although DVLA retains the

right to carry out un-notified inspections in exceptional circumstances such as, but not limited to:

Allegations of misuse of the data;

Serious concerns identified by DVLA‟s system monitoring;

Referral of serious concern from another organisation, e.g. Information Commissioner, Police, etc;

2.14.3 Customer Name will not deny DVLA audit access nor require an

unreasonable period of notice prior to allowing access.

2.14.4 Customer Name will co-operate fully with DVLA auditors and will provide full access to relevant employees, documentation, records and evidence when required. After each Audit, management will be provided with an audit report on the effectiveness of the operation of the procedures relating to the ELISE KADOE Service.

2.14.5 Customer Name will respond as required to the findings and

recommendations of any DVLA audit and will provide updates as required on the implementation of any required actions.

2.14.6 DVLA Audits will be carried out retrospectively to verify that the procedures

actually in place match those declared in the Contract. Audits may be carried out at the business premises or off-site, as appropriate. The type of inspection would depend on the agreed business context of the enquiries, as agreed within the Contract.

of 105

2.14.7 If the audit process or any other monitoring by DVLA identifies abuse of the service or non-adherence to the terms of the Contract, the consequences or proceedings as set out in the Contract will be invoked. These consequences will be appropriate to the nature of the breach of contract.

2.14.8 As a result of audits conducted or any other monitoring by DVLA, any

organisation showing a severe lack of control may be denied access to the vehicle/keeper data. Please see Annex B for details of the circumstances in which DVLA will consider suspending access to its data. The charges relating to such consequences are outlined in Schedule 3.

2.14.9 Customer Name shall not use the results of any Audit findings in any

publicity material, or in any way to support or endorse the status of Customer Name‟s procedures and/or processes.

2.14.10 DVLA reserves the right to audit any of Customer Name‟s third party

customers to ensure compliance with the Contract. 2.15. LEGAL AND REGULATORY COMPLIANCE 2.15.1 All information provided by DVLA will be handled in a manner that

conforms to the Data Protection Act, or subsequent legislation. Customer Name‟s use, treatment and storage of all information provided by DVLA will comply with all other legal and applicable regulatory requirements.

2.16. SERVICE AVAILABILITY 2.16.1 DVLA will endeavour to provide the ELISE KADOE Service for the service

hours of 00.00 to 23.59 hrs. However, ELISE KADOE enquiry (request) files must be submitted before 16.00 Monday to Friday, in line with the External Interface Specification (Appendix A).

2.17. CONTINUITY OF SERVICE 2.17.1 Where possible, DVLA will use reasonable endeavours to ensure that there

is no break in the continuity of service and will only make necessary changes to the ELISE KADOE Service after first informing Customer Name.

2.17.2 DVLA may schedule routine maintenance of the ELISE KADOE Service,

during which the ELISE KADOE Service will be unavailable. In this situation, Customer Name will be notified.

2.17.3 DVLA will not be responsible for loss of service as a result of failure in

Customer Name‟s systems or processes. 2.18. ADMINISTRATION OF THE CONTRACT 2.18.1 Guidelines on the administration of the Contract are outlined at Appendix B.

of 105

2.19. BUSINESS QUERY SUPPORT 2.19.1 Please refer to Annex A of the Contract for points of contact of escalation

for DVLA. DVLA will inform Customer Name of any changes to Annex A. 2.20. CUSTOMER REPRESENTATIVE

2.20.1 Customer Name will nominate a person (“Customer Representative”) who will be responsible for managing the relationship between the contracted body and DVLA. Please refer to Annex B of the Contract for points of contact for Customer Name.

2.20.2 It is the responsibility of Customer Name to inform DVLA of any changes in

contact details, including change of contact name, address and any other required contact information of Customer Name Representative.

2.21. COMPLIANCE WITH SCHEDULE 2 2.21.1 DVLA reserves the right to suspend or terminate the ELISE KADOE Service

at any time, if Customer Name fails to comply with any of the clauses in Schedule 2, or is given a Red assurance rating as described in Appendix D.

2.21.2 Any suspension will be for a minimum period of one month and the

completion of any action points mandated by DVLA. Where action points have not been addressed to the satisfaction of DVLA the suspension period will be extended until compliance has been achieved. In addition a fee will need to be paid (as described in Schedule 3) for the reconnection and an Audit Ranger visit or revisit date being agreed (where applicable).

2.21.3 Any revisit must have a Green assurance rating. If issues are still found to

cause an Amber or Red rating then access to the ELISE KADOE Service will be re-suspended and Customer Name will not be allowed access for a minimum period of 12 months, and a second charge will be levied (as described in Schedule 3).

of 105

SCHEDULE 3

CHARGES AND PAYMENT

of 105

3.1. BACKGROUND 3.1.1 DVLA is required to recover all costs from Customer Name for the set up,

support and maintenance and provision of the ELISE KADOE service to Customer Name.

3.2. VODAFONE AND DVLA TECHNICAL SET UP CHARGES 3.2.1 Where Customer Name wishes to have a direct ELISE link for the KADOE

Service, Customer Name is required to meet Vodafone charges and DVLA technical costs in advance in order to be set up in line with the External Interface Specification. A breakdown of the charges is as follows:

Table A Item

Charge

One-off Fees

1

DVLA Chosen Supplier

Line Installation

Fees

(a) Installation

Based on 1Mb bandwidth GCF

over 2Mb Access Bearer. This is a

one-off cost, unless Service

Provider requires a new line

installed (e.g. change of location)

£2,996.20

(b) GPS and PSN percentages fees *please see the explanations below

GPS1-2.5% of total PSN2-0.95% of total

2

DVLA Chosen Supplier Closed User Group Joining Fee

£2,050

3

DVLA Technical Set Up Costs

a) If Service Provider has not already got a direct link

£17,274

b) If Service Provider has already got a direct link for another DVLA service and wishes to add KADOE

£8,599.50

of 105

PLEASE NOTE: IF YOU ARE RECEIVING DVLA DATA VIA A SERVICE PROVIDER (DATA PROCESSOR OR INTERMEDIARY), THE ABOVE VODAFONE CHARGES AND DVLA TECHNICAL SET UP COSTS SHALL NOT APPLY.

Annual Recurring Fees

4

DVLA Chosen Supplier Line Rental Fees

(a) Annual Rental £5,719.41

(b) GPS and PSN percentage fees * Please see the explanations below.

GPS1-2.5% of total PSN2-0.95% of total

(c) Distance Charge Distance charge is the cost of the distance from the site to the nearest PoP (“Point of Presence”). Typically this can range from £50.00 to £5000.00 depending on the Postcode. This will be made known to the Service Provider following completion of the Site Survey.

Typically ranging from £50 to £5,000

(d) Parallel running (more than one line) e.g when a company is moving site and decommissioning one router and installing another at the new site

£110 per week (plus VAT at the prevailing rate)

of 105

Note 1: Government Procurement Service fees relate to:

Government Procurement Service management fees to enable the continued management of GCF, as the Framework Authority;

Fees towards the ongoing work to review compliance assessments, annually.

Note 2: Public Services Network fees relate to:

PSN fees in relation to the continued alignment towards the PSN strategy;

PSN is a set of standards and an operating model between suppliers that create the effect of one infrastructure. It is mandated for central government.

Where technical work is required in order to support and maintain the KADOE Service, the Service Provider shall pay the DVLA‟s technical costs. Those costs are as follows:

1

Table B Allocation of existing Customer to a new Link Provider (e.g. where existing DVLA KADOE Service Customer changes to a different Link Provider)

£685

2 Addition of a new third party customer (e.g. Link Provider wishing to add a new third party customer)

£685

3 Adding a new “H Code” into the DVLA‟s vehicle database. (this is dependent on the business type / model)

£685

4 Admin changes (e.g. a change of company name)

£343

3.2.2 Payment for all the Vodafone charges, listed above would not be applicable if these have already been paid under a different ELISE Data Product.

3.2.3 In event of Customer Name moving location, or adding a location, and a

new Vodafone line needing to be installed and tested, charges numbered 1 and 3 in the table above (3.2.1) will be rechargeable to Customer Name for each new location.

3.2.4 Customer Name may also need to meet additional charges stated in 4 in

the table above (3.2.1), subject to the number of concurrent active sites.

3.3. PAYMENT OF SET UP CHARGES

of 105

3.3.1 In order to collect the Vodafone installation, set up, annual line rental and

DVLA technical charges, the following process must be followed:

[i] A purchase order (including purchase order number) must be raised by Customer Name and provided to DVLA for the charges referred to above, as and when requested by DVLA;

[ii] An invoice will be raised by DVLA and issued to Customer Name

quoting the purchase order number;

[iii] Customer Name makes payment for the amount required.

3.3.2 Payment to the Agency shall be made within 30 days following receipt of the Agency‟s invoice.

3.3.3 The Vodafone installation work and DVLA technical set up work will not

commence until payment of the charges above have been received by DVLA.

3.4. AUDIT VISIT / RECONNECTION CHARGES 3.4.1 There will be a charge of £1,370 to reconnect a suspended link. 3.5. VARIATION OF CHARGES 3.5.1 The fees to be paid by Customer Name more particularly described in 3.4

(Audit Visit/Reconnection Charges) may be subject to change in line with any Fees & Charges review carried out by DVLA during the life of the Contract. Vodafone charges described in 3.2 may also be subject to change in line with any reviews carried out by Vodafone. DVLA will provide details to Customer Name of any such changes.

3.5.2 DVLA reserves the right to increase fees in line with the Retail Price Index

(RPI). 3.5.3 Where possible, DVLA will provide prior notice of any proposed charges

reviews that might affect the Service fees or charges. However, given that the charges are linked to DVLA‟s Fees and Charges regime, which can be subject to change, DVLA cannot guarantee to give a fixed notice period.

3.6. VALUE ADDED TAX

3.6.1 Where appropriate, Customer Name shall pay to DVLA the amount of any

VAT chargeable in respect of the performance of the Services in accordance with the Contract.

of 105

SCHEDULE 4

CHANGE CONTROL PROCEDURES

of 105

4.1. General Principles of Change Control Procedure

4.1.1 This schedule sets out the procedure for dealing with Contract Changes. 4.1.2 Under this Change Control Procedure:

4.1.2.1 either party may request a Contract Change which they shall initiate by issuing a Change Request in accordance with paragraph 4.3 (Change Request);

4.1.2.2 both Parties will assess and document the potential impact of a proposed Contract Change in accordance with paragraph 4.4 (Impact Assessment) before the Contract Change can be either approved or implemented;

4.1.2.3 the Receiving Party shall have the right to request amendments to a Change Request, approve it or reject it in the manner set out in paragraph 4.5 (Right of Approval);

4.1.2.4 no proposed Contract Change shall be implemented by either Party until such time as a Change Authorisation Note has been signed by both Parties in accordance with paragraph 4.5.2.

4.1.3 Until such time as a Change Authorisation Note has been signed by both Parties in accordance with paragraph 4.5.2, then:

4.1.3.1 the Services shall continue in accordance with the existing terms of the Contract as if the proposed Contract Change did not apply; and

4.1.3.2 any discussions, negotiations or other communications which may take place between the DVLA and Customer Name in connection with any proposed Contract Change, including the submission of any Change Communications, shall be without prejudice to each party‟s other rights under the Contract.

4.2. COSTS

4.2.1 Each party shall bear its own costs in relation to the preparation and agreement of each Change Request and Impact Assessment.

4.2.2 All agreed Contract Changes shall be calculated and charged as agreed between the Parties. The costs associated with delivery of agreed Contract Changes shall be agreed between the Parties including any impact on Schedule 3.

4.3. CHANGE REQUEST

4.3.1 Either party may issue a Change Request to the other party at any time during the operation of the Contract. The Change Request shall be substantially in the form of Appendix G.

of 105

4.3.2 Both Parties agree to promptly consider Impact Assessments upon receipt and shall endeavour to meet a 20 working days turnaround for responses. Where clarification is required, the timeframe will be extended to account for the delay incurred by the period of clarification.

4.4. IMPACT ASSESSMENT

4.4.1 Each Impact Assessment shall be completed in good faith and shall include (without limitation):

4.4.1.1 details of the proposed Contract Change including the reason for the Contract Change; and

4.4.1.2 details of the impact of the proposed Contract Change on the Services and both Parties ability to meet its other obligations under the Contract and any variation to the terms of the Contract that will be required as a result of that impact and including without limitation changes to:

4.4.1.2.1 the Service Description and the Service Levels;

4.4.1.2.2 the format of the DVLA Data;

4.4.1.2.3 the secure transfer of the data including Code of Connection;

4.4.1.2.4 any key dates and any other timetable previously agreed

by the Parties;

4.4.1.2.5 other services provided by third party contractors to either party including any changes required by the proposed Contract Change to either party‟s IT infrastructure;

4.4.1.2.6 details of the cost of implementing the proposed Contract Change;

4.4.1.2.7 details of the ongoing costs required by the proposed Contract Change when implemented, including any increase or decrease in the Charges, any alteration in the resources and/or expenditure required by either party and any alteration to the working practices of either party;

4.4.1.2.8 a timetable for the implementation, together with any proposals for the testing of the Contract Change;

4.4.1.2.9 details of how the proposed Contract Change will ensure compliance with any applicable Change in Law; and

4.4.1.2.10 such other information as either may reasonably request in (or in response to) the Change Request.

of 105

4.4.3 If Customer Name propose a Contract Change, which involves the processing or transfer of any Personal Data outside the European Economic Area, the preparation of the Impact Assessment shall also be subject to the following:

4.4.2.1 Customer Name shall set out in its Change Request and/or Impact Assessment (as applicable) details of the following:

(a) the Personal Data which will be Processed and/or transferred outside

the European Economic Area;

(b) the country or countries in which the Personal Data will be Processed and/or to which the Personal Data will be transferred outside the European Economic Area;

(c) any Sub-contractors or other third parties who will be Processing and/or transferring Personal Data outside the European Economic Area; and

(d) how both Parties will ensure an adequate level of protection and adequate safeguards (in accordance with the Data Protection Legislation and in particular so as to ensure both Parties compliance with the Data Protection Legislation) in respect of the Personal Data that will be Processed and/or transferred outside the European Economic Area;

4.4.2.2 in providing and evaluating the Change Request and

Impact Assessment, the Parties shall ensure that they have regard to and comply with then-current Government and Information Commissioner Office policies, procedures, guidance and codes of practice on, and any approvals processes in connection with, the Processing and/or transfers of Personal Data outside the European Economic Area and/or overseas generally; and

4.4.2.3 Customer Name shall comply with such other instructions

and shall carry out such other actions as the DVLA may notify in writing, including:

(a) incorporating standard and/or model clauses (which are approved by

the European Commission as offering adequate safeguards under the Data Protection Legislation) in the Contract; and

(b) procuring that any Sub-contractor or other third party who will be

Processing and/or transferring the Personal Data outside the European Economic Area enters into a direct agreement with Customer Name on equivalent terms, which Customer Name acknowledges may include the incorporation of standard and/or model clauses (which are approved by the European Commission as offering adequate safeguards under the Data Protection Legislation).

of 105

4.4.3 Subject to the provisions of paragraph 4.4.4, the Requesting Party shall review the Impact Assessment and, within 15 Working Days of receiving the Impact Assessment, it shall respond to the Receiving Party in accordance with paragraph 4.5.

4.4.4 If both Parties reasonably considers that they require further information regarding the proposed Contract Change so that they may properly evaluate the Change Request and the Impact Assessment, then within 5 Working Days of receiving the Impact Assessment, it shall notify the Requesting Party of this fact and detail the further information that it requires. The Requesting Party shall then re-issue the relevant Impact Assessment to the Receiving Party within 10 Working Days of receiving such notification. At the Receiving Party‟s discretion, the Parties may repeat the process described in this paragraph until the Receiving Party is satisfied that it has sufficient information to properly evaluate the Change Request and Impact Assessment.

4.5. RIGHT OF APPROVAL

4.5.1 Within 15 Working Days of receiving the Impact Assessment from the Requesting Party or within 10 Working Days of receiving the further information that it may request pursuant to 4.4.4, the Receiving Party shall evaluate the Change Request and the Impact Assessment and shall do one of the following:

4.5.1.1 approve the proposed Contract Change, in which case the Parties shall follow the procedure set out in paragraph 4.5.2 below;

4.5.1.2 in its absolute discretion reject the Contract Change, in which case it shall notify the Requesting Party of the rejection. The Receiving Party shall not reject any proposed Contract Change to the extent that the Contract Change is necessary for the Requesting Party or the Services to comply with any Changes in Law. If the Receiving Party does reject a Contract Change, then it shall explain its reasons in writing to the Requesting Party as soon as is reasonably practicable following such rejection;

4.5.1.3 in the event that it reasonably believes that a Change Request or Impact Assessment contains errors or omissions the Requesting Party shall modify the document accordingly, in which event the Requesting Party shall make such modifications within 10 Working Days of such request. Subject to paragraph 4.4.4 above, on receiving the modified Change Request and/or Impact Assessment, the Receiving Party shall approve or reject the proposed Contract Change within 10 Working Days.

4.5.2 Agreed Contract Changes will be authorised by both Parties. Following signature, the Change Authorisation Note shall constitute a binding variation to the Contract provided that the Change Authorisation Note is signed by the appropriate person(s) specified in paragraph 4.6.1 of this Schedule.

of 105

4.5.3 Following an Impact Assessment, if the Receiving Party reasonably believes that any proposed Contract Change which is requested by the Requesting Party:

4.5.3.1 would materially and adversely affect the risks to the health and

safety of any person;

4.5.3.2 would require the Services to be performed in a way that infringes any Law or is inconsistent with Good Industry Practice;

4.5.3.3 would cause any consent to be revoked (or a new consent required to implement the relevant Change in service to be unobtainable);

4.5.3.4 would materially and adversely affect the Receiving Party‟s ability to deliver the Services;

4.5.3.5 would require the Receiving Party to implement the Change in Service in an unreasonable period of time;

4.5.3.6 would (if implemented) materially and adversely change the nature of the Services (including the risk profile); and/or

4.5.3.7 would (to implement) require Receiving Party to possess legal powers or capacity that it does not have.

then the Receiving Party shall be entitled to reject the proposed Contract Change and shall notify Requesting Party of its reasons for doing so within 10 Working Days after the date on which it is obliged to deliver the Impact Assessment in accordance with paragraph 4.3.2.

4.6. COMMUNICATIONS

4.6.1 For any Change Communication to be valid under this Schedule, it must be sent to either the DVLA Representative or the Customer Name Representative, as applicable.

of 105

APPENDIX B

ELISE External Interface Specification KADOE – Keeper At Date Of Event

Version 1.6

15th

June 2011

of 105

Contents

1 Purpose

2 SCOPE 2.1 Notation ..................................................................................................................................................

3 SUPPORTED BUSINESS SERVICES 3.1 Vehicle Keeper Enquiry Service .............................................................................................................

4 PROTOCOL DETAILS 4.1 Business Level ........................................................................................................................................ 4.2 Operational Level ...................................................................................................................................

4.2.1 Validation of Data ........................................................................................................................... 4.2.2 Scheduling ......................................................................................................................................

4.3 Physical Network Level ..........................................................................................................................

5 MESSAGE SPECIFICATION 5.1 WSDL and XML Schema Structure .......................................................................................................

5.1.1 WSDL ............................................................................................................................................. 5.1.2 Request and Response Message Schemas ......................................................................................

6 THE INPUT MESSAGE 6.1 The Integration Header Elements ...........................................................................................................

6.1.1 The Integration Header XML Structure .......................................................................................... 6.1.2 The Integration Header XML Format .............................................................................................

6.2 The Request Data Element ..................................................................................................................... 6.2.1 The Kadoe Enquiry Element ...........................................................................................................

6.3 Input Message XML Schemas ................................................................................................................

7 THE OUTPUT MESSAGE 7.1 The KadoeResponse Elements ................................................................................................................

7.1.1 The KadoeEnquiry Element ............................................................................................................ 7.1.2 The ResponseDetails Element ........................................................................................................ 7.1.3 The ErrorMessage Element ............................................................................................................ 7.1.4 The PersonalDetails Element ..........................................................................................................

7.2 Output Message XML Schemas .............................................................................................................

8 EXCEPTION HANDLING 8.1 Operational Level Exceptions ................................................................................................................. 8.2 Transport Level Exceptions ....................................................................................................................

9 SECURITY 9.1 Authorisation ..........................................................................................................................................

of 105

List of Tables Table 1 - XML Schema Notation ....................................................................................................................... Table 2 - Supporting Components ...................................................................................................................... Table 3 – Message Format for Business Service ................................................................................................ Table 4 - Business Services ................................................................................................................................ Table 5 - Business Message at Business Level Protocol .................................................................................... Table 6 – Request and Response Message Schemas .......................................................................................... Table 7 – Header XML Format .......................................................................................................................... Table 8 – Kadoe Enquiry XML Format .............................................................................................................. Table 9 – ResponseDetails XML Format ........................................................................................................... Table 10 – Error Message XML Format ............................................................................................................. Table 11 – Error Message Table ......................................................................................................................... Table 12 – PersonalDetails XML Format ........................................................................................................... Table 13 - Operational Level Exceptions ........................................................................................................... Table 14 - Transport Level Exceptions ...............................................................................................................

1 PURPOSE

The purpose of this External Interface Specification is to describe the interface, or interfaces, between the

DVLA ELISE system and the external partners required to offer Keeper at Date of Event (Kadoe) requests over

the Secure File Transfer capability.

The External Interface Specification is a standard work product. It is produced during the Analysis phase of the

project. It is a key input to the subsequent Design and Build phases.

57

2 SCOPE

The scope of this document covers only the interface with the Elise system for the Business Services listed in

section 3. It covers what information is to be exchanged, how this information is structured and the means by

which it is transferred.

Internal

Service

Provider m

External

Service

Requester n

ELISE

Scope of External

Interface Specification

Figure 1 - Scope of EIS

This document does not describe the generation of data or any specific processing of information within the

Elise system, any other DVLA systems or any downstream Trading Partner Organisation systems.

58

2.1 Notation

The data models for the services described in this document are provided in the form of XML Schema. These

are shown throughout this document in graphical form using „Altova XMLSpy 2008 Enterprise Edition‟. It is

assumed the reader is familiar with XML Schema notation in particular the graphical representations used with

XMLSpy.

Graphical Representation Meaning

A solid line around an element indicates it is a

mandatory field that will/must always be

present.

A dashed line around an element indicates the field is optional and may or may not be present. An optional element is one that indicates the data and enclosing XML tags may or may not be present in either a request or response.

The sequence identifier represents an ordered set of elements.

The choice identifier represents a selection of elements.

Table 1 - XML Schema Notation

59

3 SUPPORTED BUSINESS SERVICES

This section describes the services offered by the ELISE system. The services are offered over Secure FTP.

The services are described fully via this document and the following components:

Component Description

XML Schema (XSD) data model

XML schema data model describing the elements and data types of the request and response messages provided by each service

Table 2 - Supporting Components

The component listed above provides complete details on how the services are used in terms of their messaging

and data models.

The following message format is employed for the Business Service:

Message Format Version

XML 1.1

Table 3 – Message Format for Business Service

3.1 Vehicle Keeper Enquiry Service

The Vehicle Keeper Enquiry System is a service offered via Elise for the enquiry of Vehicle Keeper details held

by the DVLA.

The table that follows provides an overview of the business services that are supported by this interface.

Business Service Description Request

Message

Response

Message

Conversation

Style

Service

Type KadoeRequest This service will allow

external customers to

request vehicle keeper

details via the Elise

interface.

VehicleKeeperR

equest

N/A Fire-and-forget File

Hosting

KadoeResponse This service will allow

vehicle keeper details

to be sent to external

customers in response

to a keeper at date of

event enquiry.

N/A VehicleKeeperR

esponse

Fire-and-forget File

Hosting

Table 4 - Business Services

60

4 PROTOCOL DETAILS

4.1 Business Level

Business Message Sender Receiver Format Transfer

Protocol

File to Elise External Customer Elise System XML SFTP

File to External Customer Elise System External Customer XML SFTP

Table 5 - Business Message at Business Level Protocol

Figure 2 - Overview Diagram of Business Level Interaction of Vehicle Keeper

Enquiry Service

4.2 Operational Level

4.2.1 Validation of Data

Please note that any data sent over the interface must be in conformance with the KADOE interface message

specification.

ELISE as a DVLA file hosting and transfer service will perform schema validation on the xml and will also

provide a limited level of business validation of the data that is passed to it through its SFTP capability.

If validation of business data is expected of the DVLA for outbound data, it will be the responsibility of the

originating DVLA Business Fulfillment Systems to provide such functionality.

Elise will modify the data that it receives, from either source, in order to transform it into the relevant format for

the final recipient.

It is the responsibility of the Service Requestor (i.e. KADOE Enquirer / Intermediary) to ensure that all data sent

to DVLA is valid against the supplied schema definitions (see section 5.1.2). Particular emphasis must be placed

on the correct naming and location of the following transaction type elements which are sent in the KADOE

Request message:

<VehicleKeeperRequest><KadoeEnquiry>

otherwise the transaction may not be processed by DVLA.

4.2.2 Scheduling

Any KADOE XML data received by the DVLA ELISE system before 4pm (Mon – Fri) will be guaranteed to be

sent onto the DVLA business fulfillment system on the same working day. Any data received by ELISE after

4pm will NOT be sent onto the DVLA business fulfillment system until the following working day. It is

therefore recommended that any KADOE XML data is sent to the DVLA ELISE system as soon as possible

(before the 4pm cut-off time) to allow this to be processed at the earliest opportunity.

Any data received after the 4pm cut-off time will be sent to the B2BG Message Broker system at 8pm ready for

submission to the DVLA business fulfillment system on the following working day.

External Service

Requester

Elise

1. Request Message (as XML) is

sent to Elise System as an ASCIIl

file using SFTP protocol PUT operation by External Service

Requestor

2. Response Message (as XML) is

sent to External Service Requester

as an ASCII file using SFTP protocol PUT operation by Elise

System

61

4.3 Physical Network Level

All data transferred between the External Partner networks and ELISE will be existing communications network

arrangements (i.e GSI, Elise Closed User Group over a Cable and Wireless (C&W) leased line and/or

Government Connect), as described in the EIS for Secure File Transfer Capability (document reference [1]).

62

5 MESSAGE SPECIFICATION

This part of the document details the format and structure of the various messages from the schema that defines

them through to field level detail.

5.1 WSDL and XML Schema Structure

This section serves to outline the structure and files that make up the KADOE Service.

5.1.1 WSDL

The KADOE Service is not a web-service and, as such, no WSDL has been produced.

5.1.2 Request and Response Message Schemas

The request and response messages are each defined in their respective XML schemas:

Schema Type Schema Name

Schema for Integration Header IntegrationHeader.xsd

Schemas for KADOE Request Message VehicleKeeperRequest.xsd

Schemas for KADOE Response Message VehicleKeeperResponse.xsd

Table 6 – Request and Response Message Schemas Please see sections 6 and 7 of this document for details associated with the respective input and output message

formats.

5.1.2.1 Schemas

All schemas are embedded within the following:

Please note that the schema versions held under source control will supersede the versions embedded above.

63

6 THE INPUT MESSAGE

The following diagram outlines the overall structure of the input message which has the root element

VehicleKeeperRequest.

Figure 3 - The Request XML Elements

The following section outlines the overall structure of the request messages.

The incoming (request) messages are split into constituent elements:

Integration Header – standard format consisting of message header related XML elements

Request Data – containing the relevant Vehicle Keeper Request XML elements.

The messages are explained in more detail below.

6.1 The Integration Header Elements

The Header element is used to identify the following attributes: the external organisation identifier, the unique

transaction id of the message (as generated by the sending party), the transaction date and unique sequence

number of the message and the version of the message. The header has the following structure.

64

6.1.1 The Integration Header XML Structure

Figure 4 - The Integration Header XML Elements

6.1.2 The Integration Header XML Format

The following table describes each of the fields contained within the Header element. Note that parent XML

elements that are purely structural have been omitted from the table for brevity‟s sake.

Element Description Data Format Mandatory

./IntegrationHeader Common integration header definition Element Y

././Date Date the transaction is transmitted. xs:dateTime N

././Version Identifies the version of the message. An enumerated xs:float numeric type (e.g. 2.0)

N

././Identification Used to hold identification details of

the service requestor

Element Y

././Identification/ApplicationId Unique code identifying the external

organisation that ultimately needs the

information (e.g. Essex City Council) and can be used to identify the type of

customer e.g. Local Authority or

private sector car parking. This value is used to authorise access to

ELISE service and will be predefined

for the sending organisation. The valid set of ApplicationId entries

will be defined by the DVLA.

xs:string which is between

1 and 50 characters in

length

Y

././/Identification/TransactionId

Unique conversation id for the

transaction. Unique sequence Id for the transaction

starting at 0000000000001 and

incrementing by 1 to 9999999999999. This will then cycle back round to

0000000000001 again.


1 and 50 characters in length.

For the KADOE

implementation, an integer value of 13 digits

is expected.

Y

././Security Used to store information relating to specific security details of the Service

Requestor.

Element N

././Security/AuthorisationId This element is used to perform

additional authorisation checks for the service requestor.


1 and 255 characters in length

N

65

Not used in the KADOE

implementation

Table 7 – Header XML Format

6.2 The Request Data Element

The structure of the Vehicle Keeper Request Data element is used to hold multiple occurrences of Kadoe

Enquiries. The structure is explained in more detail below:

6.2.1 The Kadoe Enquiry Element

The Kadoe Enquiry element is used to hold all details required to perform a Keeper at Date of Event enquiry on

the DVLA fulfilment system.

6.2.1.1 The XML Structure

Figure 5 – Kadoe Enquiry XML Format

6.2.1.2 The KadoeEnquiry XML Format

Element Description Data Format Mandatory

./KadoeEnquiry A complex element holding those fields required to make a

Kadoe enquiry

Element Y

./EnquirerId Id of the external customer dealing with the alleged

infringement

EnquirerId entries will be defined by the DVLA.

xs:string in the format of AANNN (where A is

alphanumeric and N is a

numeric value)

Y

./IntermediaryId Id of the intermediary

operating on behalf of the

enquirer. IntermediaryId entries will be

defined by the DVLA.

xs:string in the format of

ANN (where A is

alphanumeric and N is a numeric value)

N

./EnquirerReference Enquirer reference value used

to correlate KADOE request

and response messages

The EnquirerReference cannot be guaranteed to be unique

across Enquirers – i.e. one

Enquirer may enter the same EnquirerReference as that

entered by another Enquirer

xs:string of between 1 and

20 characters in length.

Allowable characters are

currently restricted to 0-9, A-Z, /, * and semi colon

Y

66

./EnquiryCode Element to hold the reason the

customer is making the enquiry.

Please note that the valid range

of EnquiryCode values will be issued in a separate document

by the DVLA. There will be an

allocated range of codes per business unit (i.e. local

authorities, car parking

operators etc).

xs:string in the format of

NNAA (where A is alphanumeric and N is a

numeric value)

Y

./DateOfEvent Element that holds the date the customer is enquiring on.

xs:date Y

./VRM The Vehicle Registration Mark

that is being enquired on.

xs:string ranging from 2 to 7

characters

Y

Table 8 – Kadoe Enquiry XML Format

6.3 Input Message XML Schemas

All input message schemas detailed above are embedded within Section 5.1.2.

67

7 THE OUTPUT MESSAGE

The output message for the Vehicle Keeper service is divided into two sections known as the IntegrationHeader

(see section 6.1), which (in principle) is a carbon copy of the data contained in the Input message, and the

ResponseData element which provides the ability to return multiple output records of different types. The

VehicleKeeperResponse element is detailed below.

Figure 6 – Vehicle Keeper Response Structure

7.1 The KadoeResponse Elements

The structure of the VehicleKeeperResponse element is used to hold multiple occurrences of the following

output message types: the KadoeEnquiry, ResponseDetails and Error Massage. Each of these outputs are

explained in more detail below:

7.1.1 The KadoeEnquiry Element

The format and structure of the KadoeEnquiry element is described in section 6.2.1. This will be a copy of the

supplied input message from the KADOE enquirer.

7.1.2 The ResponseDetails Element

The ResponseDetails element is used to hold all details required to respond to a Kadoe enquiry.

68

7.1.2.1 The XML Format

Figure 7 – ResponseDetails XML Structure

7.1.2.2 ResponseDetails XML Field Structure

Note that parent XML elements that are purely structural have been omitted from the table for brevity‟s sake. Element Description Data Format Mandatory

././ResponseDetails Element that holds the vehicle keeper details

response

Element N

./././DateOfResponse Date the Kadoe Response was provided by the

DVLA fulfilment system.

xs:date Y

././ ./PersonalDetails Complex element holding the name and address

details. See PersonalDetails Element.

Element N

../././Make Make of the vehicle xs:string ranging

from 1 to 35

characters

N

./././Model Model of the vehicle xs:string ranging from 1 to 35

characters

N

./././Engine Vehicle engine size xs:string ranging from 1 to 35

characters

N

69

./././VIN Vehicle Identification Number xs:string ranging

from 1 to 35 characters

N

../././Colour Colour of the vehicle xs:string ranging

from 1 to 20

characters

N

../././TaxClass The vehicle tax class xs:string ranging

from 1 to 25

characters

N

../././SeatingCapacity Vehicle seating capacity xs:int N

../././DateOfLicenceExpiry Date of licence expiry xs:date N

../././DateOfFirstRegistration Date the vehicle was first registered xs:date N

../././DateOfRecovery Date the vehicle was recovered xs:date N

../././DateOfTheft Date the vehicle was stolen xs:date N

../././DateOfExport Date the vehicle was exported xs:date N

../././DateOfScrapping Date the vehicle was scrapped xs:date N

../././DateOfChangeOfKeeper Date the vehicle changed keeper xs:date N

../././NumberOfPreviousKeepers Number of previous keepers of the vehicle xs:int N

../././ HardCopyIndicator A value of true indicates that no keeper details

can be generated but a paper response will be printed and returned to the enquirer

xs:Boolean N

Table 9 – ResponseDetails XML Format

7.1.3 The ErrorMessage Element

The Error Message element is used to hold of all errors encountered while trying to process a request.


Figure 8 – Error Message XML Structure

7.1.3.2 Error Message XML Field Structure


.././ErrorMessage Container that allows the DVLA to

return any errors that were encountered

while processing a previous request.

Element N

.././/ErrorCode Code related to the error found when

processing the input

xs:string of length 5

chars

Y

.././ErrorDescription A textual description of the Error xs:string of length

80 chars

Y

Table 10 – Error Message XML Format

7.1.3.3 Error Message Table

This table shows the errors or information messages that will be returned as part of the Error Reason code and

their meanings.

Error Code Description Business / System

Error

E2200 KADOE - No trace Business

E2201 KADOE - Scrapped marker set – vehicle details provided Business

70

E2202 KADOE - Exported marker set – vehicle details provided Business

E2203 KADOE - Void main file record Business

E2204 KADOE - MOD Record Business

E2205 KADOE - BFG Record Business

E2206 KADOE - Invalid VRM Business

E2207 KADOE - Invalid Date of Event Business

E2208 KADOE - Invalid date of Enquiry Business

E1101 Authorisation Failed System

E1105 Failed schema validation System

E2001 Integration Header not included within input message System

E2230 System exception encountered processing the file System

E2209 Enquiry is outside of permitted validity period System

E9999 KADOE - Unknown system error System

Table 11 – Error Message Table

7.1.4 The PersonalDetails Element

The PersonalDetails element is a reusable complex type element, used to describe the required personal details

in terms of the owner of the vehicle.

71


Figure 9 – Personal Details XML Structure

7.1.4.2 Personal Details XML Field Structure


././PersonalDetails Container to hold all name and

address details

Element Y

./././Name Container to hold person or company name details

For responses to fee-paying

enquirers, the VSS Title Code is interrogated to determine whether the

data is personal or company data. The

appropriate fields (i.e. <Title>, <Forename> & <Surname> or

<CompanyName>) will be populated accordingly.

For responses to non fee-paying

enquirers, there is no indicator returned from VSS to determine

whether the contained data relates to

person or a company. So, the data

will be populated within field

<Other>.

Element which may occur 0 or 1 times

N

././././Title Persons title xs:string of length 10

characters N

././././Forename Persons first name xs:string of length 35

characters Y

././././Surname Persons surname xs:string of length 35

characters

Y

72

././././CompanyName Company name xs:string of length 70

characters

Y

././././Other May be title, forename and surname or company name or company name

and fleet number.

xs:string of length 35 characters

Y

./././Address Container to hold address details Element N

././././AddressLine1 Address line 1 xs:string of length 35 characters

Y

././././AddressLine2 Address line 2 xs:string of length 35

characters

N

././././AddressLine3 Address line 3 xs:string of length 35 characters

N

././././AddressLine4 Address line 4 xs:string of length 35

characters

N

././././City City or town name xs:string of length 35 characters

Y

././././Postcode Postcode xs:string of length 8

characters

N

Table 12 – PersonalDetails XML Format

7.2 Output Message XML Schemas

All output message schemas detailed above are embedded within Section 5.1.2.

73

8 EXCEPTION HANDLING

This section describes the behaviour of the interface with regards to Operational and Transport level exception

handling. It identifies possible exception conditions and any associated exception message code/text. This does

not cover how to interpret individual exceptions, how to correct exceptions, how to reprocess data or how to re-

align data in affected systems after an exception has occurred.

Identification of „business level‟ and system exceptions occurring during processing of business service

request/response messages within the DVLA enterprise systems are reported within the XML message returned

to the External operators. Such exceptions will be handled within the enterprise systems and external operators.

8.1 Operational Level Exceptions

Operational level exceptions are exceptions which occur during processing of the transaction file.

Only the following operational level error, taken from document reference [3], the SSH File Transfer Protocol

Internet-Draft, is expected.

Error Code Error Condition When Error May Occur

SSH_FX_PERMISSION

_DENIED

The Service Provider cannot be authenticated. An error

will be sent to the Service Requester.

This will be reported to the Service Requester in the

error message “access denied”

During PUT request from Service

Requester.

Table 13 - Operational Level Exceptions For file hosting services, ELISE will validate the data in the files sent to the DVLA Service Provider systems

from external Service Requesters or in the files sent by DVLA Service Provider systems to Service Requesters

as laid out in the section Validation of Data.

8.2 Transport Level Exceptions

These are exceptions occurring during message transport between the Service Requester and ELISE systems

over the SFTP transport layer. The SFTP infrastructure will be configured in such a way that such exceptions

will be trapped and handled.

The following table details transport level errors that may occur during transmission of file write messages

between the external Operators and the ELISE system over SFTP. These also have been taken from document

reference [3], the SSH File Transfer Protocol Internet-Draft, which contains the complete list of possible SSH

errors. Note that, although each SFTP application may report the errors differently, these are the base SSH

errors.

Error Code Error Condition When Error May Occur

SSH_FX_BAD_MESSAGE A badly formatted packet or other SFTP protocol

incompatibility was detected.


Requester.

SSH_FX_NO_SPACE_ON_FIL

ESYSTEM

The requested operation cannot be completed because

there is insufficient free space on the file system.


Requester.

Table 14 - Transport Level Exceptions

74

9 SECURITY

All services described in this document are provided by the B2B Gateway using the SFTP protocol over a

private leased line and it is assumed that the service requester has appropriate access to this network.

9.1 Authorisation

Once authenticated, the B2B Gateway will perform authorisation on both the ApplicationID in the XML header

(populated with the ID associated with the sending party) and the EnquirerId contained within the main body of

the XML. It is the combination of both of these fields which will be authorised (on a per transaction type basis)

by the B2B Gateway. Please see Figure 10 for details.

Authorisation is performed on

the combination of the supplied

ApplicationID (i.e. the ID of the

sending party in the header

record) and the EnquirerId

(contained within the main body

of the KadoeEnquiry

transaction).

Figure 10 – Fields used for Authorisation within the B2B Gateway

In the case where data has been sent from an Intermediary, authorisation will be performed using the

combination of the supplied Intermediary ID (populated in the ApplicationID of the header record) and

EnquirerId (populated in the main body of the XML). This ensures that the intermediary is authorised to act on

behalf of the KADOE Enquirer and the Enquirer is authorised to access the service.

In the case where data has been sent by a KADOE Enquirer directly, the KADOE Enquirer ID will be populated

in the ApplicationID field along with the EnquirerId field within the main body of the XML. In this case the

KADOE Enquirer will be authorised as being able to act as an intermediary of themselves.

Please note that the KADOE Enquirer and Intermediary IDs will be agreed and assigned by the DVLA.

75

APPENDIX C

REQUIREMENTS OF APPLICANTS

FOR THE

ELISE KEEPER AT DATE OF EVENT (KADOE) SERVICE

76

1.1. STAFFING/PERSONNEL ISSUES 1.1.1 Customer Name will set out its procedures for vetting staff and comply with

these. As a minimum this will include checking the identity of new employees, confirmation of references and qualifications, and compulsory declaration of unspent criminal convictions.

1.1.2 All employees authorised to use the ELISE KADOE Service will receive any

training in the operation of the system and its associated procedures as necessary. There will be documentary evidence of their attendance on such training.

1.1.3 The requirement placed on staff to use the system in accordance with

Customer Name‟s procedures and only for authorised purposes will be set out either in a separate document signed by the employee, or in the employee‟s contract of employment.

1.1.4 There will be a defined disciplinary process in place to deal with any cases of

misuse of the system or non-compliance with procedures. This will be adhered to in the conduct of any disciplinary exercise.

1.2. USER ACCOUNT MANAGEMENT 1.2.1 User accounts will be maintained by system administrators of Customer

Name, who will operate in accordance with defined procedures as laid down by DVLA.

1.2.2 There will be an effective procedure in place for authorising the set up of

new user accounts, and for the prompt deletion of accounts no longer required.

1.2.3 Access to Customer Name‟s E‟s systems in relation to ELISE KADOE must

be protected by unique user credentials for each employee who has access to the ELISE KADOE system. User IDs will not be shared between employees of Customer Name.

1.2.4 There will be a direct link between a user account and a specific individual. 1.2.5 User accounts will only be accessible on input of a password of at least eight

characters, which is required to be known only to the user, and which must be changed no less frequently than every 90 days.

1.3. PROCEDURE DOCUMENTATION 1.3.1 Customer Name‟s procedures for operation of the ELISE KADOE system will

be defined in a document, which is approved by Customer Name‟s senior management.

1.3.2 Customer Name Senior management will approve changes to the procedure

document.

77

1.3.3 As appropriate to their role, users will have a copy of the sections of the procedure document relevant to them.

78

APPENDIX D

AUDIT COMPLIANCE REQUIREMENTS AND

SAMPLE AUDIT FORM

79

1.1. AUDIT COMPLIANCE PROCESS In line with clause 2.14.1 of the Contract, DVLA reserves the right to conduct an audit of the systems and processes used by Customer Name to ensure that adequate security practices are being maintained. After each Audit, Customer Name management will be provided with an audit report on the effectiveness of the operation of the procedures relating to the ELISE KADOE Service.

Where the report highlights issues or risks surrounding performance of the Contract, DVLA reserves the right to consider or suspend Customer Name‟s access to the service, as outlined in Table 1 below, and referred to in clause 1.13 of the Contract.

TABLE 1: The following table describes the circumstances in which DVLA will consider suspending access to its data by ELISE KADOE Customers:

AMBER

Warning of Suspension

Electronic link will be suspended unless action point(s)

rectified immediately

RED

Immediate Suspension

Link suspended until assurance given and evidence

provided that issues have been addressed.

AMBER Poor physical security at their own sites, including non closure of the system and screen access when not in

use

AMBER

Inaccurate or incomplete log of enquiries made in the format prescribed in the agreement with the resultant

cases being unavailable to back up those enquiries as an audit trail. (e.g. why enquiry was made, what the

information was used for and the result of the issue)

AMBER No links for mismatched or incorrect enquiries to the subsequent correct enquiry and no audit trail cross-

referencing the two enquiries

AMBER Holding the data on more than one database or copying the Data or linking it to any other database without

written approval of the DVLA Contract Manager.

AMBER Staff are unaware of, and do not adhere to, security arrangements or when access to data is permitted

AMBER Unauthorised reasons for requests, unauthorised user access or improper use or storage of data has not been

investigated, and identified and/or DVLA has not been notified

AMBER No response to Internal Audit Action Point

RED Contract not signed or not current e.g. change of company name, new contract not signed and returned

The following items will also require a visit or revisit by a DVLA auditor to ensure that concerns

have been addressed:

AMBER

Absence of hard evidence (such as an eye witness report from an employee of Customer Name, or a Section

9 statement from a member of the public) about the incident. Obtaining information from the electronic

Service too early in the investigation.

AMBER

Records containing personal information not retained in a secure manner (including a hard copy of the

record (VQ5/VQ7), screen prints, microfilm copies, reports or other data which have been supplied or

derived from DVLA‟s system in any format)

RED Unauthorised users have access to systems and the data or absences of a suitable identification and

authentication system or no records exist to identify users

RED Use of data or additional reasons for requests being made outside those specified in the contract have not

been cleared with DVLA before changes take place

RED Data has been transferred, sold or made available in any way to any third parties unconnected with the

original purpose of the enquiry

RED Evidence of breaches of statutory provisions, legislation or other legal requirements affecting the service and

persons employed in relation to the use of this service

RED Evidence of a range of issues that together demonstrate DVLA data is exposed to risk

RED No response to Internal Audit Reminder of failure to meet Action Point(s)

80

1.1. SUSPENSION, RECONNECTION AND AUDIT REVISITS

1.2.1 The process for auditing, suspending and reconnecting customers, and conducting audit revisits is as follows:

If the outcome of the audit (or any other report by DVLA) results in a GREEN or AMBER assurance rating, a set of actions will be mandated to Customer Name by DVLA with a stated timeframe for delivery.

Where Customer Name has failed to respond to and deliver the stated actions by the date requested (and after a reminder has been issued by DVLA), Customer Name will be suspended from the ELISE KADOE Service for a period of one month.

Where the outcome of an audit (or any other report by DVLA) results in a RED assurance rating, Customer Name will be:

a) immediately suspended for a period of one month, or b) permanently removed from the ELISE KADOE Service, depending

on the severity of the breach.

Where Customer Name is suspended, DVLA will supply a set of mandatory actions to be delivered by Customer Name in a set timeframe. A DVLA audit visit will be scheduled to confirm that actions have been delivered to the satisfaction of DVLA.

Any revisit must have a Green assurance rating. If issues are still found to cause an Amber or Red rating then the link will be suspended and the Customer Name will not be allowed access for a minimum period of 12 months and Customer Name will need to apply in order to rejoin the ELISE KADOE Service.

This schedule also applies to Customer Name‟s third party customers, in line with clause 2.14.10 of the Contract.

Charges to reconnect and conduct DVLA audit visits or revisits on ELISE KADOE Service customers are outlined in Schedule 3.

2.1. AUDIT REQUIREMENTS OF 3rd PARTY CUSTOMERS (For Intermediaries) 2.1.1 In line with clause 2.10.1(l) of the ELISE KADOE Contract, Customer Name

(where acting as an Intermediary) is required to audit their approved list of third party customers at least once during a rolling three year programme, and notify DVLA of any changes or issues. Evidence of the audit must be made available to DVLA upon request.

2.1.2 This Appendix sets out the minimum requirements and measures for

Customer Name to satisfy while conducting auditing activities on their third party customers.

81

2.2. Minimum Requirements

2.2.1 The audit form (shown below) should be completed as part of the third party

customer audit, which should be carried out via a site visit at least once during a rolling three year programme for all of Customer Name third party customers and within the first three months for any new third party customers being introduced. Increased frequency may be necessary if any vehicle keeper complaints are received or if there are any known issues or there is considered to be a higher level of risk. (Telephone audits are not acceptable.)

2.2.2 All completed forms should be retained for a minimum period of two years from the date of the audit. Copies of completed forms should be sent to DVLA Representative.

2.3. Samples for Audit

2.3.1 Vehicle Registration Marks should be randomly selected and Customer Name

must produce on request, a full audit of the third party customer on their permitted purpose for requesting and the subsequent use of the data.

5% of all enquiries made per third party customer must be audited. However, where that percentage produces less than 3 enquiries, a minimum of 3 enquiries must be audited. Where that percentage produces more than 50 enquiries then a maximum of 50 audited enquiries is acceptable.

The audit planning and decisions should be risk based and higher levels of audit checks are encouraged wherever possible or whenever needed.

2.3.2 Documentary evidence of these checks must be retained by Customer Name and provided to DVLA Auditors upon request.

2.4. Internal Staff Control Measures 2.4.1 All staff employed by a third party customer are subject to employment

checking and screening appropriate with the handling of sensitive data. In addition, Audit Manager activity and processes will be monitored regularly by their direct managers or supervisors.

2.4.2 The Key Performance Indicator‟s (KPI) for supervisors should include:

Completed audit forms for every relevant client

Usage monitoring

Account Plans and compliance audits

A Business Information report to confirm status of company

82

2.5. Audit forms 2.5.1 A sample Audit Form, which covers the DVLA monitoring requirements, is

shown below.

83

AUDIT FORM

ENQUIRIES RELATING TO DVLA KADOE (KEEPER AT DATE OF EVENT) SERVICE

Audit Manager: Date: Organisation Name: Contact Name: Address / location: DVLA enquirer code (i.e. AANNN): Electronic data

User ID and password required to enter database Are all enquiries logged: -

On the system Manually Does management ever check them?

Do employees have a written procedure? Does any internal review body become involved?

What is the data used for? How long is enquiry log kept? What happens to the data after case closure?

84

Manual systems Who has access to the information when received in the post? Where and how are Hard Copies of VQ5 forms, which include keeper details, kept?

General

Is your premises / building secured? Are all keepers provided with a copy of the appeals procedure when contacted? Are you registered with the Information Commissioner? Are original queries centrally stored and retained? How is data transferred from central office to outstations or sub-contractors? Is there a reconciliation check between incoming and outgoing enquiry volumes? Is there a reconciliation check between incoming and outgoing enquiry volumes?

Yes/ No Data Protection Registration Number: Expiry date: What does the permission cover?

85

Is the information ever passed on to third parties (e.g. Debt collectors)? Please confirm your DVLA authorised permitted purposes in the table below. (e.g. Parking On/Off Street under Traffic Management Act 2004) Sample Vehicle Registration Mark (VRM) journeys Chart the journey of a sample VRM (see „Samples for audit‟) taken from the previous six months data, and please supply the following:

The full reason for the enquiry, including the date of event.

Supply details of the evidence / documentation to support the enquiry.

Confirmation that data and records are stored and handled securely and in line with the Cabinet Office Mandatory Minimum Measures as stated in the Contract.

Confirmation that any mismatched or incorrect registration mark enquiries are cross- referenced with correct files.

Confirmation that any data relating to incorrect registration mark enquiries is deleted securely as stated in the Contract

VRM: VRM: VRM: Once completed please send copy of proforma to DVLA Representative, as shown in Annex A.

86

APPENDIX E

MANDATORY MINIMUM MEASURES

87

Summary of Cabinet Office Guidelines: Mandatory Minimum Measures for Data Processing / Data Sharing Organisations

Government has put in place a core set of minimum mandatory measures to protect information, to apply across central Government. They are minimum measures in that they oblige individual Departments and agencies to assess their own risk, and those organisations will often put in place a higher level of protection.

1. Information is a key asset, and its proper use is fundamental to the delivery of

public services. The public are entitled to expect that Government (and data sharing organisations) will protect their privacy and use and handle information professionally. Departments are best placed to understand their information and to protect it, but need to do so within a context of clear minimum standards ensuring protection of personal information.

2. This document sets out mandatory specific minimum measures for the protection of personal information. “Personal information” is defined in section A, below. All organisations handling DVLA data must also comply with other obligations, such as those under contracts, codes of connection, and the law. The material in this Annex reflects good practice as set out in the Cabinet Office Information Assurance series.

3. In complying with these Measures, DVLA has a responsibility to ensure that all commercial arrangements which are concerned with data handling are fully compliant with these Cabinet Office requirements. In turn, DVLA must ensure that data sharing organisations in receipt of data from DVLA perform to these standards.

Specific minimum measures to protect personal information

4. Those in receipt of data from DVLA must be particularly careful to protect personal data where its release or loss could cause harm or distress to individuals. DVLA will determine what information is contained in this category with each entity in receipt of data. This must include at least the information outlined below and handle all such information as if it were at least “PERSONAL DATA” (please see section A below) while it is processed or stored.

4.1 Preventing unauthorised access to protectively marked information

When Personal data and/or information is held on paper, it must be retained in secure premises and locked away. When information is held and accessed on ICT systems, controls should be in place to ensure that access is only granted to individuals whose role necessitates it and the physical location of systems is also on secure premises. Exceptions to these conditions can only be applied with prior agreement by DVLA.

Use of removable media (including laptops, removable discs, CDs, USB memory sticks, PDAs and media card formats) for storage or access to such data is not permitted as part of the data handling procedures.

Deviation from this guidance is exceptional and will only be acceptable after prior approval and guidance from DVLA.

88

4.2 Secure Disposal

In accordance with Data Protection law, recipients of protected data should dispose of it when there is no business need to retain it. All material of this nature should be disposed of in a secure controlled manner. As a guideline, you should:

destroy paper records containing protected personal data by incineration, pulping or shredding (to shredded wheat) so that reconstruction is unlikely; and

dispose of electronic media that have been used for protected personal data through approved secure destruction processes.

4.3 Access rights

Access rights should be minimised in respect of each of the following:

The default should be that no member of staff has access to protected personal information. If access is necessary, it should be to the smallest possible sub-set of records;

o The hierarchy should be:

no access

ability to view only aggregated data

ability to view only anonymous records

ability to view material from single identifiable records

ability to view material from many identifiable records simultaneously;

Functional access, including: searching, amendment, deletion, printing, downloading or transferring information.

4.4 Citizen-facing work

Organisations providing services on behalf of Departments and agencies need to ensure that citizen facing services are secure, while being easy for people or their representatives to use. Where possible, the same protective measures should be taken in transacting business with individuals as when information is stored or used within Government, but Departments will set their own proportionate standards in this area so long as those standards (and possible alternatives service routes) are clearly explained.

In summary: key principles Departments and their suppliers/contractors MUST protect sensitive personal information from unauthorised access, release or loss; Sensitive personal information MUST be handled in accordance with specific measures covering access, removable media, controlled disposal, authentication, audit, forensic readiness and citizen-facing work

89

A: Minimum scope of protected personal data

Any information that links one or more identifiable living person with information about them and whose release would put them at significant risk of harm or distress.

From a commercial perspective, this means that all parties who engage with DVLA in a data sharing arrangement need to be mindful of their responsibilities around this area.

1. one or more of the pieces of information which can be used along with public domain information to identify an individual

combined with

2. information about that individual whose release is likely to cause harm or distress

Name / addresses (home or business or both) / postcode / email / telephone numbers / driving licence number / date of birth

[Note that driving licence number is included in this list because it directly yields date of birth and first part of surname]

Sensitive personal data as defined by s2 of the Data protection Act, including records relating to the criminal justice system, and group membership

DNA or finger prints / bank, financial or credit card details / mother‟s maiden name / National Insurance number / Tax, benefit or pension records / health records / employment record / school attendance or records / material relating to social services including child protection and housing

These are not exhaustive lists. Departments should determine whether other information they hold should be included in either category.

B. Any source of information about 1000 or more identifiable individuals, other than information sourced from the public domain. This could be a database with 1000 or more entries containing facts mentioned in box 1, or an electronic folder or drive containing 1000 or more records about individuals. Again, this is a minimum standard. Information on smaller numbers of individuals may warrant protection because of the nature of the individuals, nature or source of the information, or extent of information.

90

APPENDIX F

DVLA OFFSHORING GUIDANCE

91

DVLA Guidance: Offshoring Personal Data From a commercial perspective it continues to be an attractive prospect to store, hold and access data outside of the UK. However, this has significant implications for DVLA from an information assurance perspective and potentially introduces new risks (especially reputational damage) and can incur additional costs in managing or mitigating those risks. In line with HMG policy, the Agency position is that bulk DVLA personal data (where the total number of records off-shored is 1,000 or more) is not to be stored or accessed overseas. However, the Agency recognises the complexity of the global data environment, and variations in regulation between storage within the European Economic Area and elsewhere. Our main concern is to preserve the confidentiality, integrity and availability of the data, and to minimise risk to this asset. These notes advise on procedures. 1: Process for the approval of proposals to store personal data overseas Any proposals to store, process or access „bulk‟ personal data sets overseas must be approved by DVLA‟s Information Assurance Group [IAG]. Where smaller data sets are being considered for offshoring IAG will still need to provide advice. All commercial customers utilising DVLA data are obliged to comply with these requirements. For the avoidance of doubt, primary contractors will be responsible for ensuring their sub contracted resources also comply with these guidelines. The service elements offered by offshore service providers may include, but are not confined to:

Software development, including research.

Database administration

Data processing centres (including hosting), data warehouses (including archive facilities), and web hosting;

Call centres and help desks;

Hardware development, supply and maintenance;

Developing and writing code used in processing DVLA personal data. 2: Definitions. „Offshoring‟, in the context of DVLA data sharing agreements, would be defined as the transfer of a business process to another country under the existing contractual obligations agreed with the Agency. „Near-shoring‟ for UK companies indicates the transfer of business activities within the wider European area. Under UK law, personal data cannot be transferred to a country outside the EEA unless that country ensures an adequate level of protection for the rights and freedoms of the data subject. The Agency is responsible for assessing whether the data intended to be offshored could be categorised as personal data. This assessment includes:

92

the business case for offshoring,

security management responsibilities,

contractual agreements,

risk assessments,

on-going security management (including incident reporting and business continuity).

Any changes to agreed offshoring/nearshoring arrangements will need to be agreed with the Agency prior to implementation.

3: Criteria.

The criteria applied by IAG to contracts that involve data offshoring, is as follows:

3.1: Compliance with the Mandatory Minimum Measures (Appendix E).

As an initial step the following points need to be addressed:

a) What data or information is the supplier/contractor collecting, holding, accessing, processing or transferring on behalf of the Agency (e.g. anonymised, non-personal, personal etc);

b) Ensuring that risks are identified and data is protected, but in cases of personal (and especially protect personal data) the DVLA will ensure that the supplier/contractor meets the specifications set out in the Cabinet Office Minimum Mandatory Measures

Any organisation proposing to offshore DVLA data must provide evidence of:

Technical security – security of the systems in play including access controls, monitoring protections for the integrity of systems including firewall, anti-virus, etc.;

Physical – location of their buildings and protection for them, where are the backups created/stored, conditions for handling data;

People – who has access to the data, how are they vetted, have they been vetted by us or do they need to be?

Culture – does the culture value data and treat it as an asset? What evidence do they have that the necessary culture is in place to protect data?

3.2: Assurance that approval from Senior Information Risk Officer (SIRO) that adequate information risk assessment and protection is in place.

The approval of the SIRO approval is required for existing contracts that involve some form of offshored data processing. To do this, IAG and Commercial Services Group (CSG) will need:

A short description of what DVLA data is being considered for offshoring at any stage in the process;

Why is the data process offshored, if there are alternatives and if so what the implications of bringing it to UK would be;

93

Assessment of the risks to confidentiality, integrity and availability of the data offshored which includes probability and impact;

Duration of the Contract and any break clauses;

Compliance/non compliance with minimum measures in Appendix E.

A short assessment by the Information Asset Owner of the security measures in place and whether they think they are adequate and whether any weaknesses exist;

Any plans already agreed to improve security or terminate the offshoring arrangements and timescales for these changes.

The Agency may at this point undertake a Privacy Impact Assessment, in compliance with the requirements of the Information Commissioner‟s Office.

The initial point of contact regarding this Appendix will be CSG.

94

APPENDIX G

CHANGE REQUEST FORM

95

Appendix G

Change Request Form

Cr no.: Title: Type of change:

Contract: Required by date:

Action: Name: Date:

Raised by:

Area(s) impacted (optional field):

Assigned for impact assessment by:

Assigned for impact assessment to:

Customer reference no.:

Full description of requested contract change:

Details of any proposed alternative scenarios:

Reasons for and benefits and disadvantages of requested contract change:

Signature of requesting change owner:

Date of request:

96

APPENDIX H

IMPACT ASSESSMENT FORM

97

Appendix H

Impact Assessment Form

Cr no.: Title: Date raised:

Contract: Required by date:

Detailed description of contract change for which impact assessment is being prepared and details of any related contract changes:

Proposed adjustment to the charges resulting from the contract change:

Details of proposed one-off additional charges and means for determining these:

Details of any proposed contract amendments:

Details of any service levels affected:

Details of any operational service impact:

Details of any interfaces affected:

Detailed risk assessment:

Recommendations:

98

APPENDIX I

CHANGE AUTHORISATION FORM

99

Appendix I

Change Authorisation Note

Cr no:

Title:

Signed on behalf of DVLA:

Signed on behalf of Customer Name:

Signature:_____________________

Signature:_____________________

Name:________________________

Name:________________________

Position:______________________

Position:______________________

Date:________________________

Date:_________________________

100

ANNEX A

POINTS OF CONTACT AND ESCALATION FOR DVLA

101

ANNEX A 1. DVLA KADOE Helpdesk Contact Details If you encounter any technical problems with the ELISE KADOE service which are within DVLA‟s area of the service boundary please contact the PACT Service Desk. Telephone: 0870 241 4552 Fax: 0870 241 4553 E-mail: [email protected] The helpdesk will be able to resolve your call more promptly and effectively if you ensure you have the following information available when you contact the desk:

Name (an/or) alternative contact;

Site/Location;

Contact telephone number;

Reason for call (e.g. fault, enquiry, request). If you have a fault then please give necessary details and describe any attempted recovery actions (error messages, dialogue boxes etc.) When you call: (i) A helpdesk technician will record your details on the call management

system. (ii) You will be given a reference number (please note it and quote it in any

follow-up discussion). Fujitsu will notify Customer Name if the Service is not available, this will only be on an exceptional basis. Maintenance work is usually conducted out of office hours. Customer Name will notify the DVLA of any delay in accessing the information. Any technical support required in regard to links between Customer Name and its customers must be supplied by Customer Name. If Customer Name submits KADOE Service request files via a Data Processor (as a Service Provider), Customer Name should direct any business or technical support enquiries to the Data Processor in the first instance. 2. Business Contact Details Driver and Vehicle Record Enquiries (DVRE) KADOE Helpdesk General KADOE service or contractual related queries should be directed to the KADOE Service Support team in the first instance through the following email address: [email protected]

mailto:[email protected]

mailto:[email protected]

102

DVLA Business Owner Joint Head of Central Casework Group Tel: Email: DVLA Senior Operations Manager Senior Operations Manager Driver and Vehicle Record Enquiries (DVRE) Tel: Email: 3. DVLA Information Security and Assurance (including Incidents) Head of Information Security Information Assurance Group Tel: Email: 4. Escalation Process DVLA

Operations (DVRE/KADOE)

Senior Operations Manager

DVLA Business Owner

5. Contracts Administration DVLA Senior Commercial Manager Commercial Services Group Tel: Email:

103

ANNEX B Customer Name‟s Representatives are, as follows: Commercial Manager: Name: Telephone: Email: Operational Manager:

Name: Telephone: Email:

104

ANNEX C

INTERMEDIARY CUSTOMERS

105

ANNEX C In accordance with 2.10.1b Intermediary Companies shall ensure the following terms, clauses, permitted purposes and principles surrounding security and transfer of data within the Contract with DVLA are in place with their customers. GENERAL TERMS AND CONDITIONS 1.1 LAW 1.7 INSPECTION 1.10 DISCLOSURE OF INFORMATION 1.13 SUSPENSION OF SERVICE 1.16.3 CONSEQUENCES OF TERMINATION AND BREAK 1.19 DATA PROTECTION 1.21 RETENTION OF DOCUMENTATION AUDIT ACCESS 1.23 DISPUTE RESOLUTION 1.27 RIGHTS OF THIRD PARTIES 1.30 INTELLECTUAL PROPERTY RIGHTS 1.32 USE OF BRANDS, LOGOS AND TRADEMARKS 1.33 USE OF DVLA‟s NAME SCHEDULE 2 – SERVICE DESCRIPTION 2.2.2 DETAILS OF PROVISION 2.3 BACKGROUND 2.4 DEMONSTRABLE BUSINESS NEED 2.5 ACTUAL DATA NEED 2.7 QUALITY OF RECORDS 2.8. INPUT/OUTPUT DATA (Excluding 2.8.1) 2.9 CONDITION OF USE 2.10 ADDITIONAL CONDITIONS OF USE FOR INTERMEDIARY COMPANIES

(d,e,f,g,h,i,j,l and m) 2.11 SECURITY REQUIREMENTS (Excluding 2.11.3 and 2.11.4) 2.13 STORAGE OF RECORDS 2.14 AUDIT AND ASSURANCE 2.15 LEGAL AND REGULATORY COMPLIANCE APPENDIX D - AUDIT COMPLIANCE REQUIREMENTS AND SAMPLE AUDIT FORM

contract between the driver and vehicle licensing agency ...€¦ · vodafone and dvla technical...

Documents