Close
Articles and Briefings
Contributors
There is an increasing requirement for collaboration on major aerospace & defence projects in order to realise innovation and efficiencies for customers. As a result, one of the biggest challenges facing the aerospace & defence industry is how to establish shared data environments ("SDEs") that enable truly collaborative working whilst protecting the security and integrity of the data they contain. This is especially true in relation to the servicing of large or complex platforms, such as ships and fast jets, where it is common for support work and capability upgrades to be modelled on a digital twin by one contractor before being delivered on the asset by another.
Challenges emerge due to the sensitive and proprietary nature of the initial data set, which may have evolved through a development programme extending over twenty to thirty years and then be needed throughout the asset's operational life. The baseline data set will probably have been generated by many contributors operating under a variety of historic contractual frameworks and continue to be updated until the asset is finally decommissioned.
When contemplating use of an SDE, a critical consideration is your future commercial strategy and the long-term needs of your customers. The way in which a service company will want to use IP and data is fundamentally different from the approach needed by a technology business. And if you are a service company, what is the nature of the service that you are seeking to offer? For example, is your strategy to build a business around the support of assets or the delivery of SDEs (as this will affect which intellectual property rights are of most value to you and how you choose to use them)? The agreements that are put in place to deliver and operate the SDE need to leave no room for doubt as to the extent and duration of any user rights that are being granted and the ownership of any associated software or other material that is developed.
This article provides a checklist of the main legal issues that need to considered at the outset and, where relevant, addressed in legal agreements (e.g. SDE User Agreements) in order to establish the framework for an SDE and govern the relationships between those that use and benefit from it. These need to align with and compliment any common support approach that is being applied by the customer.
First steps
It is important to begin by mapping out:
- the data that needs to be shared
- the purposes for which it is to be used and
- the organisations / individuals that need to see it (in each case considering the nature of their interest and input).
This is similar in many ways to the exercises carried out to consider the management of personal data for compliance with the General Data Protection Regulation, only with a different set of parameters.
During the mapping exercise, issues with the tool (the software and hardware that will be used to create and manage the SDE) need to be distinguished from issues with the content (the data that will be shared and modified using the tool). For example, you may have the right to use a database tool and own the server on which the database is kept, but that does not mean that you own or have rights to use the information that is to be stored or modified within them.
Once that mapping process has been completed, consider the issues set out below. Of course, this is not intended to be a comprehensive list and the issues that arise will be different in each circumstance. It is important to consider the legal and regulatory issues at the outset and then design the management of such items into the system architecture and data management protocols. It is also important that risks and concerns are identified early so they can be flagged during any internal approvals process and pricing review.
Content management
Who is allowed to input material, who is allowed to modify it and who is allowed to use it? Does this reflect the rules of any common support methodologies and the rights granted by prior contracts under which the material was developed? If the intention is to delegate approval to those tasked with the day-to-day delivery of tasks, what role does the SDE play (i.e. does it flag items for approval or is that managed by the delivery teams themselves)?
Is the intention for the SDE to provide a single point of truth (for example in relation to access and user rights to the content in the SDE or quality / health & safety approvals that have been issued)? If so, consideration needs to be given as to how that will operate in practice (and the associated rules of working captured or referenced in the supporting legal agreements). If the SDE automates those processes, how are urgent operational requirements addressed?
What are the contractual (and common sense!) rules on confidentiality concerning the data in the SDE? Does the access control system (and its configuration) reflect the terms of contracts placed or proposed for the development and delivery of the SDE?
Intellectual property
What licences are in place to use the SDE platform and tools (and under those agreements, who manages and holds the risk of a data or IP breach – the users who access the data or the provider of the SDE who controls access)? Do the licences granted extend to all users? Have you sufficient oversight of any subcontractor's supply chain to know who is in their wider team?
Does the software proposed as the basis of the SDE contain any open source elements? If so, caution is needed as in some cases the use of open source components can restrict your options concerning the future licencing of material derived from them.
What licences are in place for the use of background IP (have you obtained the necessary third party consents), and who owns and can use the IP that arises during the life of the SDE (whether completely new material or modifications to the original data set)? How far does the licence to use extend? Do the access controls of the SDE reflect any restrictions on use?
Is the material that is inputted into the SDE manipulated or translated in any way as part of the collation / ingestion process? If so, it is worth considering the legal implications of this.
How will the SDE be customised in terms of trade marks and branding? Will your logo feature or that of your customer? If you are branding this as your product, is your customer expecting that? If you plan to use your customer's logo, have you been given permission?
Will the SDE have a novel user interface or system architecture, or valuable algorithms, that you will want to protect and use elsewhere? If so, it would be worth seeking guidance on your ability to protect and exploit such intellectual property.
Risk & liability
Who holds the risk and liability in relation to a failure of the SDE? In order to consider this an exercise first needs to be undertaken to assess the different risks that are present. For example, those arising from a temporary interruption to data services, a loss / corruption of data or a security breach.
There are, of course, technical mitigations for this (such as security access controls and back-up systems), but they are not the subject of this article. The risk assessment and resulting register should note all key risks and then how they are addressed, even if standard and accepted practices are being used in mitigation. The risk register needs to note not only what the mitigation is but who is responsible for deploying it.
While this article does not address technical cyber security options, it is important to consider whether a cyber-risk rating been assigned by the customer and ensure that the levels of access control and encryption (etc.) meet the required standards.
Regulatory compliance
Is the content of the SDE subject to any national security controls? For example, have you considered the terms of any applicable Security Aspects Letter.
Is the content of the SDE subject to any export controls (for example, the U.S. ITAR)? If so, then export control specialists will need to advise on the limitations on sharing and the suitability of the SDE for holding such content. Specific approvals, agreements or licences may need to be issued by the relevant government(s) before the information can be made available via the SDE.
Will the content contain any personal data? If so, the system needs to comply with the General Data Protection Regulation and related legislation, and a process created for identifying and reporting a breach. Have appropriate privacy notices been included in the SDE user interface design? Will all users be required to acknowledge the terms of use (as set out in the relevant SDE User Agreements) when they log in?
Please note that the advent of Brexit could have a significant impact on how data transfers are managed between processers in the UK and the EU27, and existing agreements may need to be amended to address this.
Are there any other regulatory compliance or project management requirements (e.g. arising under the Construction (Design and Management) Regulations 2015 or from the use of Building Information Models) that need to be designed into the SDE system architecture?
Many of the issues raised in this article (for example those concerning export control and management of modifications to data) will require that the SDE tool tracks who has seen and modified information and can provide a credible audit trail. This is useful not only for delivering the requirements of the SDE, but also for demonstrating contractual and regulatory compliance.
Customer requirements and third party dependencies
What are the wider customer requirements (present and future)? For example, have you considered whether the customer may want to expand the scope of the SDE?
What are the terms of any agreement under which the SDE has been funded and developed? Do they align with the terms of agreements that govern the pre-existing data that will be kept in the SDE? Do they dictate who owns any material that is generated?
How reliant are you on third party providers (for example, your I.T. or cloud service providers)? In the event that they let you down, temporarily or permanently, do you have a business continuity / disaster recovery plan to set out how you will maintain delivery of the SDE? Does your insurance cover deal with issues relating to the SDE and the data within it?
Close down and disputes
What happens to the SDE tool and data once the initial contract expires?
Who has access to the data after expiry / termination and is the customer permitted to use it when commissioning a replacement SDE from another provider?
What level of support is the customer entitled to expect from you during the final stages, and after the end, of the contract for the provision of the SDE?
How will you resolve any disputes? There may be legal issues but also practical day-to-day disagreements as to how data was modified (for example, if the records of the SDE do not accord with an individual contractor's work book). How will you ensure that disputes are resolved with minimum disruption to the service provision?
All of the above issues can usually be addressed at the outset and reflected in practical, user-friendly agreements that genuinely facilitate the collaborative intentions of the parties. The identification of risks and mitigations not only helps to futureproof the solution, but also enables effective pricing and demonstrates to the customer that the proposed solution is robust and viable.
