- Home
- Digital Passport: Consultation questions from industry
Digital Passport: Consultation questions from industry
Principles
In combinable crop supply chains, merchants are trading grain between growers and processors with a range of possible destinations available for loads after they have been collected from growers. The only feasible solution for ensuring buyers have access to the food and feed safety data at the point they need it is for a passport to travel with each load.
Some other crop sectors (e.g. potatoes and vining peas) require passports per load, but in those supply chains, universal industry-wide passports are not used, instead, passports are specific to individual companies.
Regardless of crop type, all buyers will require food and feed safety information to be shared either per load or per contract.
The consensus from the leadership group is to use the word obligation, to describe the return of weight and quality data through the DP for all loads. The business case has been revised to include this language consistently.
Yes, if receivers require a digital passport, they are obliged to provide weight and quality data back through the DP system over and above any other methods of feedback used. This obligation to feedback data means receivers entering weight and quality data which will be held in the central DP hub and be available to the sender, haulier, and merchant simultaneously, in real-time. If receivers already have established channels to feed this information back, then growers and other senders will be able to choose how to access this. One useful feature is that once fully transitioned, weight and quality data relating to all loads a grower sends will be available in the DP system regardless of who the load is sold to.
Any other industry aggregated data usage, including permission 2 (aggregated for food and feed safety) will be controlled by the data governance group. The exception on publishing aggregated data for a sector with 5 or fewer businesses, in respect of competition law, does not apply to permission 1 (day to day passport data shared between supply chain parties), it does apply to permission 2 (aggregated for food and feed safety).
This question is outside of the business case and cannot be answered within the business case.
For imported crops, it is the merchant’s responsibility to confirm with their customer whether a passport is required for lorry movements of grain from port to processor. The TASCC assurance scheme rules explain this process. More broadly, any imported grain has to meet the same food and feed safety standards as domestically grown grain.
However other countries do not have the same level of market coverage of farm-level assurance schemes as is found in the UK and therefore additional testing and monitoring is applied to imported crops to make sure these meet the UK’s food and feed standards. These controls are sometimes referred to as gatekeeper protocols, and include crop sampling, testing and analysis done to internationally agreed standards set by the Grain & Feed Trade Association (GAFTA), to ensure global consistency.
Read the AIC website for useful further information in this area.
There are two aspects to this answer. Assurance scheme rules and standards stipulate that passports should be used in order for consignments to be considered to be assured. However, growers, storekeepers, and hauliers each need to take responsibility for completing their own sections of the passport, whether paper or digital and this will be checked at intake. Loads are likely to be delayed at intake, or even rejected, if the buyer requires a passport and one is not available, or it is not fully complete.
Find out more about whose responsibility it is to input data.
Ownership, governance, funding and costs
Yes, the Data Group agreed for the British Oat & Barley Millers’ Association (BOBMA) to be represented on the Data Governance Group.
Yes, the Leadership Group agreed for BOBMA to be represented on the Ownership Group.
Yes, the wording in the business case has been revised for clarity. It is important to note that no saving for this has been included in the cost benefit calculations. The example is included as a benefit that might be available for some growers and stores who are in a position to react to the real-time crop quality results.
The scenario is that for a series of loads supplied, real-time crop quality results are fed back for each accepted load. Those results show that there is a trend in one of the quality parameters which is moving close to the contractual threshold. In this scenario, the grower or store may have an opportunity to adjust supplies before a rejection occurs if they have different quality stocks of grain available. Not all growers or stores are in this position.
The period from the point at which work starts on the DP, to the point the paper system is due to be phased out, is 27 months. It is widely believed that this is long enough for businesses large and small to prepare for the switch, including those that will need to scope out, budget and plan for investment in updating software or in integration. Any longer, risks introducing extra costs and uncertainty. The business case wording has been updated to reflect this.
Yes, the development and leadership groups have discussed all elements of the cost benefit analysis financial figures and have made revisions where agreed. The updated cost benefit analysis can be found in the updated business case.
Yes, in addition to the benefits already stated in the business case, some additional ones have been identified:
- The digital system is more robust than the paper system from a data integrity standpoint. Access to the digital system is controlled through registration of individuals linked to businesses. Each passport section can only be completed by the party whose responsibility it is to complete it. The digital system contains an audit trail which will record which user entered or adjusted which data point and when. With the paper passport, there are no such controls and different parties can write or amend data which is not theirs.
- The DP's data governance proposals have been scoped out in detail outlining who owns what data, which party can see which data and when, and the framework for the potential use of aggregated and anonymised data in future all overseen by an industry representative data governance group. Contrast this to the paper passport where there is no data governance framework, and a lack of clarity on who owns what data. As a consequence, growers have no control over what processors and other receivers can or cannot do with data they have supplied.
The grower and haulier representatives and their trade associations were consulted on this point, and all confirmed that from data they held, the growers and HGV driver ownership and usage of smartphones is at the same level as the wider population. Subsequent small-scale surveys conducted at a grain intake indicates that in-fact the level of smartphone usage amongst drivers is likely to be higher than in the general population and the business case has been updated to reflect this.
Integration with one system has been included in the business case costings. If as a course of integrating with the DP, businesses choose to integrate systems within their own business that are currently not connected, then this will bring other, wider efficiency benefits beyond introducing a DP, and so the costs of this should be kept separate.
The development group discussed this and agreed that neither of these costs should be included. The amount of smartphone data required in order to use the DP is very low (see question 41) and given how far data charges have reduced over recent years, most users will require less than £1 worth of data per year for the DP.
The guide integration costs have been revised completely as a result of industry feedback. In addition, extra detail has been provided on the options available to businesses to consider, which will be particularly of interest to those diverse businesses having storage and haulage operations alongside their merchanting business. Anonymous case studies have also been included outlining potential costs for two businesses who have quantified their own costs to integrate.
No. The development and leadership groups discussed this question and there is no evidence to suggest that this might happen. A grain intake survey revealed that 99% of drivers already have a smartphone indicating that more drivers might already be set up to use digital technology than was originally envisaged. Through the DP consultation in winter 23/24, all TASCC haulage participants received notification of the proposals. In addition, a number of smaller hauliers were contacted 1-1 to discuss the proposals and none raised the question of increasing haulage rates.
Yes, this will be made clearer in business case.
Yes, the Leadership Group agreed a charge would be applied for the use of the digital passport for non-levy paying businesses and those trading non-levy crops, e.g. imports and pulses. It is recognised some imported grain may not need to use a digital passport because it may go directly into a processing facility.
Find out more about charges for non-levy paying businesses and crops.
Grant funding will be sought to cover the build and running costs for the first three years. AHDB's Cereals & Oilseeds sector council are responsible for decisions on how levy is spent.
No. Surveys have indicated that 99% of drivers already have a smartphone. Training materials will be readily available for drivers to familiarise themselves with the system. Haulage companies will also see some benefits from moving to a digital passport, such as reduced waiting times from issues with the paper passport such as missing stickers and data. Surveys show that 3% of loads are affected in this way.
No. Integration is entirely optional. The DP system will also be available to access via a website and mobile app.
The Leadership Group agreed group member time costs are not included, and this time is given graciously by participating group members in both development of, and involvement with, the digital passport, for the benefit of the industry.
A core system governance group is proposed to oversee development and take key decisions both for the build phase and long-term. A larger user group representing all crop sectors and all parts of the supply chain will be called on as required, especially to input into system design and user testing and acceptance. System governance core group:
- Chair – elected from:
- Grower – NFU
- Grower – NFUS
- Haulier
- Miller
- Maltster
- Feed compounder
- Merchant/storage
- Red Tractor
- SQC
Basic development and maintenance is built into the business case costings. Any significant new functionality development or system improvement needs to be discussed and agreed by the ownership group, data governance group and system governance group. Funding will also need to be secured to cover the development costs.
Find out more about funding for development and maintenance costs.
Digital passport system – proposed process
Discussion across both the data and development groups about the critical role that merchants play as contracting parties with growers, hauliers and processors highlighted that providing merchants with passport visibility earlier in the process will be beneficial in ensuring supply chains logistics run as smoothly as possible. This is particularly the case when there are issues to resolve, e.g. incomplete or incorrect passports.
If merchants can see the passport with an issue, it will be easier for them to help rectify the issue with their contracted grower and haulier. The proposal is that at the point growers create passports, it will be optional for them to add the merchant that they have sold the load to. Once added, this merchant will have full visibility of the passport data added by grower and haulier, and later in the process, the weight and quality data added by the processor.
AHDB and the contracted developer will work with the system governance group to develop functionality to meet industry's needs. As an overall concept, weight and quality data will be added to the original passport data so all data relating to a load is available in one place. For a mixed load sourced from two growers, there would be two passports and therefore data fields would exist to enable two weights and two sets of quality data to be added.
On the basis that drivers either visit a public weighbridge or use the onboard weigh scale to weigh the first consignment before loading the second consignment, and travelling to the intake, separate net weights for each consignment would be available and can be uploaded by the merchant. Processors will not have the individual net weights and so will not be able to enter this. On the basis that mixed loads have one set of quality results, the same results can be added to both passports. If there are more than two consignments in a load, the same principle applies.
System design proposals
In a modern development environment following agile methodologies, a continuous integration and continuous delivery/deployment (CI/CD) type approach to development would be used. There will be continuous assessment and improvements made to the system covering upgrades, security changes etc rather than one big release followed by no development or improvement for several years followed by a second big release. The ongoing running cost budget includes sufficient developer resource to cover these ongoing upgrades.
Whilst this has not been included in the specification of industry requirements that went out to tender, this could be explored with the system build contractor during the build phase.
Yes, we will add this to the relevant places in the business case.
Yes, this will be possible. However, the haulage office will only be able to access passports if the driver's device has Wi-Fi or mobile data signal after the passport is transferred from the grower or storekeeper's device.
The DP will access the store level assurance statuses from assurance databases where available. This will mean that temporary stores will show as unassured after the 31 October cut-off date. For those growers with production only memberships, and without storage on-farm, their assurance status will be shown as assured for movement up to 31 October.
Yes, this functionality will be available either for the haulage office, or the driver to change.
Yes, the intention is that, where storage locations are held within assurance databases, it will be available to grower and store businesses within their DP accounts and will appear as a drop-down list which can be used to populate that section on the passport. This will include temporary and long-term stores for growers.
Find out more about what data is stored for populating the DP.
All TASCC stores will require passports for grain coming into their facilities. The TASCC scheme rules provide some flexibility on how this is achieved. Some stores require one passport for each individual load. Other stores will accept one passport to be used per day, per crop, and per vehicle, and if stores choose to operate like this then the DP will be able to accommodate it.
Yes, all of the mycotoxin data fields present on the current paper passport will be replicated on the digital system.
In this instance, information relating to a rejected load will only be uploaded to the DP once Wi-Fi or mobile data signal is available. It is possible that information relating to the same load accepted at a second online intake will be available within the DP first.
The DP will be able to accommodate this. It is important to note that communication between supply chain businesses in connection to the rejection should take place outside of the DP as it does today. The DP will only be a channel between intake and the other parties involved in a load to share weight and quality data, so the fact that data relating to the rejection at an offline intake is not available initially is not envisaged to be a problem.
Both growers/storekeepers and hauliers have a contractual obligation and are individually responsible for completing their own sections of the paper passport and this remains the same with the introduction of a digital passport.
No. Growers and storekeepers will have the ability to choose how their business receives weight and quality data. There will be options to sign up for email or text message notifications and options to choose who within the business receives these. Weight and quality data will remain held in the system and will be accessible to users for users when they log in, alongside the original passport data. As such notifications are optional.
A completed passport will be indicated by the sender and haulier declarations both being populated. A passport in this state will remain available indefinitely until such a time as the load is accepted by an intake. There is no time limit.
It has been conservatively estimated that each passport handled by a grower/storekeeper or a driver on their mobile device, will require up to 50KB of data when the device is operating without Wi-Fi. This means that for a grower with 2000 tonnes of crop (approx. 70 artic loads), this would consume 3.5MB of data if all passports were completed using mobile data and no Wi-Fi access.
For a full-time driver, handling 3 passports per day for a 5-day week, for a full year, (780 passports) with no Wi-Fi and 100% mobile data, would require 39MB of data. With mobile data prices having dropped significantly over recent years, this means that depending on the contract, the typical data cost associated with a year's worth of passports could cost less than £1 per user.
There are different options for this depending on the operations of the receiving business. All receiving businesses can enter weight and quality data directly into the DP web portal alongside the passport that the data corresponds to.
For those merchant businesses who have contracted out the 'receiving' to another business, i.e. for export port operations or for third party stores, then there will be the option for merchants to bulk add weight and quality data to the DP by uploading a spreadsheet, which could contain the data for all loads received on a particular day. In order to tie the details together, for this to work, the intake staff would need to record the passport ID number on their spreadsheet for each load at the time they check the Digital Passport.
Find out more about how data can be input without integration.
This requirement will be checked at point of registration on the DP. The registration page will require an exact match between business names and will cross-check with other relevant data. Any queries in this process as a result of mismatched names will be handled and supported by the helpdesk prior to the DP registration being approved.
The DP will be able to access assured storage location data from assurance databases and whether they are long-term or temporary stores and their status on a given date and will display this data on passports. Production only members with no storage will also be accommodated and their business level assurance status will be displayed which allows them to dispatch crop on an assured basis up to 31 October.
Find out more about how the DP works for farmers with short-term storage.
Clear rules are available through the assurance schemes for how owner members and contract farming arrangements are handled from an assurance perspective. The DP will accommodate this and follow the guidance already available for these scenarios. The precise 'how' will be clearly established and mapped with the system developer working closely with assurance body and industry representatives through the build phase.
Find out more about how the DP works when crops are stored elsewhere.
No, because the merchant will not be connected to that load until the rejecting intake uploads the merchant identity to that load alongside the weight and quality data.
The development group discussed this and agreed that this option should be available to hauliers.
No. A destination is not added to a passport when it is initially created by growers or storekeepers. The destination is not linked to a passport until the load arrives at intake and the passport is transferred from the driver to the intake team.
This approach means there is complete flexibility to change plans last minute, without anyone needing to change anything on the digital passport. This includes re-routing loads to a different intake when already on the road.
The winning bidder through the recent tender process has proposed to use QR codes rather than Bluetooth, so any limits on device pairing will not be an issue.
Yes. Detailed design like this will be undertaken prior to each development phase with appropriate industry practitioner input to make sure the proposals are fit for purpose and work for people on the ground.
In addition, functionality will be available within the system for businesses to set parameters against incoming passport data which can automate some or all passport checks. For example, a company may say they want their intake team to be presented with a warning when a grower store or haulier is unassured, and a prohibited material has been entered as one of the last three loads.
These checks would be set depending on which data points are critical for each business. Any receiving business choosing to integrate their software with the DP could also choose to automate passport data checks by importing the raw passport data into their software at intake.
This option will be explored in phase 2 or 3 development. It will definitely not form part of the initial build phase.
Yes. In drafting the specification of industry's requirements for the DP, it was decided that if businesses purchasing non-assured grain require a passport, they should be able to use the DP system. In these situations, if an unassured grower creates the passport, the passport will display the fact that the load is unassured.
No, this is currently out of scope.
Yes. The existing AHDB helpdesk is well set up to support pig producers without access to computers or smartphones to create their accounts and electronic pig movement licences. For the DP, the same processes can apply. A grower would telephone the helpdesk and there is a one-off process to set up the company and user access. This would entail:
- Providing the helpdesk with the data needed to set up their account; this includes assurance scheme membership details, and the data will need to match before the DP account is created
- Following appropriate security protocols to ensure that the individual can verify their identity and their connection to the business
- Setting up further extra users for the business as required
- Signing up growers to receive weight and crop quality data notifications via text message if required
This one-off registration process will probably take around 10 minutes, provided the caller has all their details to hand.
Once completed, the grower can phone up to create passports as required, usually when the lorry has arrived. The helpdesk will follow the security protocol to verify the caller's identity and then:
- Run through the necessary questions to obtain all the data needed to populate the passport
- This data can be set up as a template which can be used to create further identical passports in future
- The passport will be completed by the grower completing the declaration over the phone
- The grower will then provide the helpdesk call handler with the identity of the haulage business and driver and the passport will be allocated to that driver
- The driver will be able to access the passport in the DP app whenever they have internet access and will be able to complete their passport sections and declaration
This passport creation process will take around 5 minutes for the first one for each crop. Any subsequent identical passports can be replicated from the template and be created quicker, with the helpdesk checking that no details have changed since the template was initially created.
Find out about creating a DP without a smartphone or computer.
Wi-Fi and mobile phone data, such as 3G or 4G, are two different ways of connecting to the internet. Wi-Fi uses a fixed access point such as a router within an office or home which devices can access, usually by logging on with a key or password. Mobile phone data (3G, 4G, 5G) is distributed by mobile signal masts. Wi-Fi is usually faster than mobile phone data networks.
Data allowances are purchased as part of mobile phone contracts or by pay as you go. When you access the internet via mobile networks, you will use some of this allowance. 4G is over 5 times faster than 3G networks. 5G networks which are currently being rolled out across UK cities are up to 10 times faster than 4G.
There will be a number of safeguards to help reduce the chance of this issue occurring and measures to prevent commercially sensitive data being shared, if it does. This includes:
- Receiving businesses will select the appropriate merchant for each load from the list of merchant businesses that they have an established working relationship with, not from the entire list of merchants in the DP system: therefore merchants, if allocated incorrectly, would receive data from receiving businesses they have a relationship with anyway
- Once the selection has been made, users will be required to double check the selection and ID numbers are correct
- Rules agreed within the data governance framework discussions mean that merchants will be able to access relatively few passport data points supplied by the grower and haulier, and none that would identify either business, so even if a merchant were incorrectly added to a passport, they would not be able to access any commercially sensitive data
Yes, any mistakes made can subsequently be rectified by the receiving business.
Passports will remain available to drivers, until such a time as the intake team click 'accept'. This means that if a load is rejected, the driver will still have access to the passport and will be able to transfer it for a second time when they arrive at the next destination.
In terms of weight and quality data for rejected loads, the company rejecting the load will add the relevant quality data and rejection reasons, but not the weight. This information will be visible to the merchant and supplying grower or store, but not to the second intake, unless the rejection was for food or feed safety reasons. If the load is accepted at the second intake, a further set of quality data can be added alongside the net weight. Drivers will not need to do anything.
No. Where buyers require these, they should continue to be shared separately as they are today.
Storage locations and assurance statuses will be two separate data points. Locations will be imported into growers' and stores' DP accounts at the point they first register. Those storage locations will be available to select when operating both online and offline. If there is any subsequent change to the storage locations within assurance databases, there will be functionality to allow company admin users to update this and import the latest data into their DP account when online.
Assurance statuses will be checked in real time during the passport creation process when Wi-Fi or mobile data signal is available. Any status check will be date and time stamped, and the date and time of the most recent check for any storage location will be held within that business' DP account and this is what will be displayed for any passport created offline. For any passport arriving at intake, where the intake staff want a more recent assurance status check than the one displayed on the passport, they will have the ability to perform a check there and then, but they must have internet access to enable this.
Yes, it is mandatory, the receiver must put the last seller's name into the system. The only exception is when the receiver has purchased loads directly from growers.
The answer to all these points is yes. All businesses registered on the DP system can have as many different users as they require. Each user will have their own log in details and can use whichever device they prefer. Any activity undertaken by any user attached to a business will be recorded and be accessible to other users from that same business. For example, all completed passports will remain accessible for all growers within their DP account.
Yes, the development group discussed and agreed that this would happen. It has been included as a requirement in the specification of industry requirements which went out to tender.
Yes, but only when the load ID is considered alongside the merchant's name. Load IDs will be unique for each merchant. The system governance group will need to decide during the build phase whether this validation should be included.
Yes, this was included in the specification of system requirements put out to tender.
There are a number of ways the system can be designed to make this as intuitive and user friendly as possible without relying on free-type data entry. It is intended that the descriptions used for materials will correspond to the IDTF database descriptions.
However, this database contains hundreds of materials. To make it easier for haulage businesses, company admin users will be able to select from the IDTF list, the materials their business commonly hauls, and it is this reduced list which will appear as a drop-down list for users to select from.
Data governance
No, the exception on publishing aggregated data for a sector with 5 or fewer businesses, in respect of competition law, does not apply to permission 1 (day-to-day passport data shared between supply chain parties), it does apply to permission 2 (aggregated for food and feed safety).
Find out more about exceptions of publishing aggregated data.
The industry representative data governance group will be responsible for deciding the approach to the different data permissions. The group's representation is outlined in business case section 6.2. It is envisaged that their approach will be conservative, particularly in the first years of operation, and that where a group member has reservations about a particular usage request, further clarification will be sought before reaching a decision.
The permissions process is outlined in section 6.2. Since the original business case was published, following a request from industry the proposals for permission 3 data access have been brought forward and the proposals are also included in this section. As system host and data processor, AHDB will carry the responsibility for data protection. AHDB have a long track record of safely and securely managing commercially sensitive data throughout its history, including in the cereals and oilseeds sector.
No, it would not be automatically void. As outlined in business case section 6.2.4, for supply chains with fewer than five companies (e.g. oilseeds), specific agreement on data aggregation will be needed with all parties agreeing to the dataset being created.
The sensitivity of any dataset in this area will likely be determined by the data requested. It would be possible to create an aggregated and anonymised oilseeds dataset, comprised of grower-owned and supplied data, which contains no reference to the destination of the oilseed crop and therefore would be regarded as non-commercially sensitive, provided it met all other threshold requirements.
The system will provide industry access to data for as long as required. TASCC scheme rules state 3 years, International Sustainability & Carbon Certification (ISCC) states 7 years. The data group agreed that the retention time should be extended to 8 years. After 8 years, the data remains available within the DP but will be archived. It can still be accessed on request. The Data Governance Group will oversee this area.
Auditors will not have direct access to the DP system. At audit, members of staff for the business being audited will be able to search for passports and passport data and will be able to generate reports summarising their passport system usage for a stated period of time and provide such information to the auditor as required. As such, no data governance implications are foreseen.
Business case section 6.2.4 outlines the process for data requests under permission 2 (food and feed safety). This includes calculating the costs associated with fulfilling the data request. Section 6.2.5 outlines the process for AHDB usage on behalf of industry under permission 3. It is envisaged that this approach would also be taken with any permission 4 requests in future if the data governance group decides to permit these. Freedom of information (FOI) request costs will be calculated and charged in the same way. Current regulations outline an appropriate limit of £450 (18 hours charged at £25/hr).
After a passport is completed, data fields will remain editable by growers/storekeepers and drivers up to the point it is accepted at intake. This will allow users to rectify mistakes and allow updates to fields such as the vehicle registration number which may require updating if a different tractor is used to deliver a trailer, to the one that collected it. Users will only be able to update the data they are responsible for.
Once any updates have been made to data points by either grower/storekeeper or driver, after they have completed their declarations (which would usually signify the point their part is complete), the system will automatically perform fresh assurance checks. It will be possible for purchasing merchants, who are linked to the passport by growers, to sign up for notifications alerting them to passports where data has been updated. The helpdesk will also be able to update data on behalf of growers/storekeepers and drivers if they are unable to perform the updates themselves. The in-built system audit trail will record which user updated which datapoint and when.
It is right to withhold the grower's details, including collection address, from selling merchants: in the event of a string trade, where more than one merchant is involved, the selling merchant is not the party contracting with the grower. However, further discussion with industry has led to a revised proposal which will give growers the option to add the merchant they have sold to at the point the passport is created, which in turn with allow them to see passports. Question 26 provides further information on how this will work.
The data processor for the DP will be AHDB under the current plans outlined in the business case. In the event that the DP proceeds, data security will be AHDB's responsibility. AHDB will also hold the responsibility to ensure that the build contractor's data security measures are robust and adhered to, throughout the contract period.
Backup and support
AHDB operates a helpdesk to support a range of industry services, including the pig industry's electronic movement licences.
The helpdesk is comprised of 5 full-time call/email handlers and a manager. The proposal is to add two full-time people to this team. All team members will be trained to support the digital passport, so there will be 7 people available to support at peak times.
The transition from paper to digital, from the start of beta testing to the end of paper passport usage, is planned to be 27 months, with businesses switching to digital throughout that period. This will give time to see what level of support industry requires and adjust the level of support through the help desk accordingly.
It is recognised that grain intakes do not operate on a 9−5, 5-days a week basis, so a pattern of extended hours will be agreed with industry which will flex through the season and be extended further during harvest. The call centre technology allows the team to closely monitor the timing of calls and emails meaning that extra resources can be made available if it's shown for example that there's a regular daily peak at 8am. Examples of areas where the helpdesk will be able to support users are:
- Initial business and user registration processes
- Log in and password problems
- Help in completing data, especially when users have local issues such as loss of Wi-Fi, or a broken device
- Assist with the transfer between users
- Reporting system bugs for resolution
Find out more about the role and functionality of the help desk.
As owner of the system, AHDB will remain liable; it is up to AHDB to ensure there is sufficient liability cover/insurance to cover these instances.
There are a number of ways in which users can be supported in these circumstances. Users will be able to log in using any of their available digital devices, including smartphone, tablet, laptop, or desktop computer.
In-built functionality:
- Makes it easy to download a completed passport as a pdf
- Provides the ability to email it to self or to someone else
- Provides flexible options for individual users to work around central system unavailability or local issues
In addition, any passport created by a grower or store can be accessed by other users registered with that business.
It is important to note that through the transition period, working practices are likely to adapt to mitigate these risks too. In the event that a phone is broken, individuals would need to contact the support desk, who would be in a position to help, although it's recognised that they may need to borrow someone else's phone to do this if the device could not make a call.
This could include transferring a passport from one user to another, provided that the appropriate security checks were passed. It could also include adding data to a partially complete passport in order to complete it.
Find out more about what to do in the event of a broken or flat phone.
The focus throughout the build phase will be to design and build a system which is highly available with stringent service level agreements. The build contractor is ISO 22301 certified which means for services they develop, they have audited processes in place focusing on business continuity and disaster recovery management.
The system will be hosted in Microsoft Azure, meaning the service will be highly secure, resilient and with high availability. There will be automated data replication, backup, and recovery regimes to support business continuity, coupled with hosting across two geo-redundant datacentres. This means that if there is an issue with one system it will automatically switch to the other hosted in an entirely different location. This will limit system downtime to an absolute minimum. Service level agreements will include system uptime requirements, which will be agreed with the system ownership and governance groups.
AHDB has an Incident Management Policy which covers eventualities like this and other cybersecurity events, like ransom attacks. This policy provides clear processes to be followed based on the incident severity. In addition, practical contingencies will be required, not just in case the central system goes down but in the event there are local issues such as a phone with low or no battery. It has been clearly stated by industry that reverting to a blank paper passport, such as the one used today, is not an option in emergencies.
In-built functionality, which makes it easy to download a completed passport as a pdf and enables it to be emailed to self or to someone else, will provide flexible options for individual users to work around central system unavailability or local issues.
Planned maintenance events will be rare as it is proposed to use technology which allows new deployments without taking the system offline. Any required planned maintenance will take place overnight or at weekends in time windows agreed with industry.
Find out more about what happens in the event of system failure.
A call to the support desk should be made who can transfer the passport between users provided that the appropriate security checks are passed.
Find out more about what happens in offline transfer between devices fails.