Statement of Works ("SOW") are often used as part of master technology service agreements to describe the scope of services to be provided by a supplier and to fix the price for those services. However the parties to the contract often fail to clearly describe the services to be provided, or the timescales for service delivery. This often leads to delays and arguments during the service provision phase, which in the worst cases can lead to litigation.
Whether you are a supplier keen to avoid "scope creep", or a customer wishing to avoid the inadequate delivery of a critical project, the following issues should as a minimum always be addressed in an SOW:
Scope of Services
The work that the supplier is contracted to perform should be clearly and accurately described. Any gaps between the supplier’s services and the customer's business and technical requirements should be discussed and addressed.
Technical Requirements & Specifications
The SOW should clearly describe the customer's business and technical specifications and requirements. A clearly defined set of specifications will make it difficult for a supplier to avoid their obligations, whilst protecting the supplier from an increase in its budgeted project delivery costs due to a required increase in scope by the customer.
A project plan is essential for ensuring clarity with respect to the parties' obligations to perform certain activities by agreed timescales. The project plan should clearly describe the scope, timescales and framework for the project. A key issue about project plans that is often forgotten, particularly in the case complex projects, is that the SOW should contain an obligation on the parties to agree a project plan by a set deadline, for example, within six weeks of the contract signature date. Alternatively, the parties could agree that the delivery of the project plan itself becomes a deliverable to be achieved by a milestone in the "design" phase.
Deliverables and Acceptance Testing
All deliverables should be clearly described, with any "key" or critical deliverables identified and milestone dates for each deliverable allocated and agreed within the project plan. An agreed acceptance process should be detailed in the SOW (it could also be agreed at the MSA level to save time). However it is to be incorporated into the agreement it should be made clear that the method for determining the successful achievement by the supplier of a particular deliverable will be solely by the application of the acceptance procedure and associated acceptance criteria.
Customer's Obligations and Project Assumptions
A supplier will often require the inclusion in the SOW of a list of customer obligations and/or project assumptions. The supplier should carefully consider the list of customer obligations and/or project specific assumptions it wishes to include, to identify those obligations which if not performed, or assumptions which if proven to be invalid, could lead to changes to the project schedule, project deliverables and project costs. The Customer should also pay attention to the list of customer obligations and assumptions to ensure that they only contain obligations for which it is right and proper to assign responsibility for performance to the customer, and in the case of any assumptions, only those that are fundamental to the operational and commercial profile underpinning the deal.
This will not always be the case, but generally speaking a choice should be made between a "fixed fee arrangement" or for fees to be calculated on a "time and material" basis. If the services are to be performed for a fixed fee the SOW should include all expenses to be incurred and any applicable taxes. The Supplier will only be able to invoice the customer for the fixed fee amounts. In the case of a time and material arrangement the Supplier will perform the services on a time and materials basis at the rates agreed and detailed in a rate card set out in either the MSA or in an annex to the SOW.
The above list is not exhaustive by any means and there are many other issues to consider depending on the type, size and complexity of a particular technology services project. Nevertheless, if the above issues are addressed during the negotiation phase of a SOW this will increase the chances of the project not only being delivered on time and on budget, but also in accordance with the customer's requirements.
Cookies (or similar technologies) are usually placed on an individual user's device by either the website publisher or by an advertising network organisation ("ad network") that is permitted by the website publisher to place cookie, to collect data in order to build a profile of that individual user based on their online search history. This profile of the individual can be used to target them with advertising relevant to their preferences and interests. This is known as targeted advertising or online behavioural advertising ("OBA").
The relevant provisions of the Privacy and Electronic Communications (EC Directive) Regulation 2003 (PECR 2003), which governs the position in the UK as to when and how a website publisher can place a cookie on an individual user’s device states that a person shall not store or gain access to information stored, in the terminal equipment of a subscriber or user unless the subscriber has given their consent, after being provided with "..clear and comprehensive information.." about the purposes of the storage of or access to that information.
The Regulation also introduces the concept of profiling or automated decision making, which is relevant to the functioning of OBA. In essence, individuals now have the right to be informed about the existence of automated decision making and subject to certain exceptions, the right not to be subject to automated decision making or profiling.
However, the fact is many ad networks are active on multiple websites; collecting, using, storing, aggregating and then transferring huge amounts of data to each other and this is often not made clear to users, in violation of the Regulation and its principles. The net effect is that users may have no idea who is collecting, using or storing their personal and non-personal data and in many cases are not even aware that their data is being used to build profiles about them. If they are made aware of collection of personal data, it is presented as a positive, to enable the website publisher to provide the user with a more personalised service. This is potentially risky for users, because profiles are generated by mathematical and statistical modelling of the information collected about users and are not infallible. The results of such modelling can therefore potentially lead to inaccurate and/or misleading results about an individual.
In the new world of online privacy regulation, it is no longer enough to simply have policies in place, without operational compliance. To minimise their risk of non-compliance with the law website operators should as a minimum ensure that:
Further, where a joint controller relationship between the website publisher and an ad network could or does exist, the user must be made aware of the conditions of that collaboration. This not only allows the user to understand who is responsible for protecting their data, it is also beneficial for website publishers and their ad network partners to understand in the context of their commercial relationship which party is legally responsible for compliance with the relevant privacy regulations.
Much of the discussion to date around blockchain and distributed ledger technology (DLT) has been about making data more secure. This is unsurprising given that the technology is designed to ensure:
Further, it is not always clear whether the application environment in which DLT is intended to operate enables compliance with related privacy regulation. For example, GDPR Articles 12 – 22 set out data subject rights including rights of access, rectification, erasure, restriction and portability. The blockchain principle of immutability referenced above would seem to run contra to these data subject rights, if personal data is included in the blocks that make up the chain.
The use of "on-chain and off-chain" deployment models, is an example of how areas of potential regulatory non-compliance can be addressed. This type of hybrid deployment model could be used to keep part of the transaction on-blockchain and any personal data processing off-blockchain. One possible use of on-chain off-chain blockchain technology is identity verification. Where an organisation is subject to know your customer (KYC) regulations, blockchain and DLT technology could be used to verify a prospective customer's identity, without the need to collect, store or process any personal data to verify such identity.
In this case, the personal data required to validate an individual’s identity, will be confirmed by a trusted third party and held by the individual in an encrypted digital wallet. The organisation wishing to verify the customer’s identity for the purpose of KYC, would use public key/private key authentication to verify the individual’s identity, without ever having to further process this personal data in the form of identity checks with for example, credit reference agencies.
A digital identity solution of this kind would be very attractive to organisations who might wish to supply or market goods and services to consumers, but who are also keen to ensure, to the greatest extent possible, that their KYC processes remain outside the scope of the GDPR and other related data privacy legislation. However, this would require the organisation to "trust" the validity of the personal data held in the digital wallet, so some form of authentication or certification of trusted third parties would be required.
Does this not then defeat the purpose of blockchain and distributed ledger technology if not all data is stored on the blockchain and the very information that is most important to protect i.e. personal data for the purposes of identity verification, still sits on a centralised database albeit with a ‘trusted third party’?
When embarking on a software or application development project, a key consideration should be the development methodology to be used. Generally, the commissioning party ("the customer") will have the choice of an "Agile" or "Waterfall" style of development. The methodology selected by the customer will often depend upon whether the customer wishes to have flexibility during the development cycle, or whether it wishes to agree a detailed set of business specifications and technical requirements before the developer begins work. The choice made will of course inevitably have legal and commercial implications. These implications should be identified and addressed in a software development agreement between the customer and the developer. Some of the factors to consider in making the decision are set out below.
Agile software development methodology allows the customer to develop its requirements during the project phase in short, frequent development cycles. Agile development is flexible and scalable; it enables the scope of a project to be changed based on feedback received during these short development cycles. In short, the specifications can be changed post contract signature, without the need to follow a strict and potentially time consuming change control process. However, this does not mean that the parties should abandon recording any agreed changes to the high level specifications agreed at the very beginning of the project.
Therefore, if you are a customer thinking about using Agile you should ask yourself:
Waterfall software development methodology is focused on agreeing a detailed set of business requirements and technical specifications prior to the commencement of work. Detailed documentation is required for each project phase, including technical specifications, which set out measurable deliverables and performance criteria.
If you are a customer thinking about using Waterfall you should ask yourself:
It is also possible to use a mixture of Agile and Waterfall during the development. For example, the early scope and analyse phase of the project could be completed using Waterfall, whilst Agile development principles are applied to later or selected phases of the build. In these circumstances care must be taken to ensure that the correct contracting principles are agreed and applied at the appropriate stages of the development. For example, the point at which testing and acceptance should occur may differ depending on which methodology is used.
Although, Agile is flexible and collaborative, it does not equal "zero paperwork". It is still advisable (for both parties) to agree: a contract, project plans, interface designs and technical specification documents. After all, you would not embark on a software development project based on the Waterfall methodology without addressing issues concerning project governance, deliverables, testing and acceptance, warranties, cost and IP ownership - to name just a few. Agile is not a "free for all" in terms of scope and scope change, so organisations should still consider all of the above even when using the Agile methodology.
GDPR Article 35: Pop up Quiz! Do you know what this section of the new Regulation requires companies to do if developing new products and services (including software) could result in a "high risk" to individuals?
To find out or to arrange your free one hour initial consultation please contact us.
The introduction of Regulation (EU) 2016/679, otherwise known as GDPR ("the Regulations") has resulted in significant changes to the UK and European data protection landscape.
As businesses large and small consider the practical and operational implications of these changes, an interesting aspect might be the relationship between the providers of cloud services and their clients. An example, of this can be seen in Article 28 of the new Regulations, which sets out a prescriptive and detailed set of data protection obligations that controllers are required to contractually impose on their processors.
Of course, under GDPR the client would normally be the controller of personal data, and the cloud provider its processor. At a time when businesses are increasingly reliant on cloud computing services, the provisions of Article 28 will create an interesting challenge for small businesses who as controllers, are now required to ensure the detailed list of obligations required under Article 28 are included in their cloud services contracts.
One particular obligation under Article 28(2), is that the processor must provide the controller with notice of any sub-processors it wishes to appoint and the controller will have the right to object. Typically, large cloud providers are reluctant to move away from their standard terms of business, and many adopt a "take-it-or-leave-it" position in contract negotiations, in particular with respect to their preferred sub-processors. However, European data protection supervisory authorities have indicated that an inequality in the bargaining position between a cloud client and its supplier will not release the small cloud client from its obligations under Article 28.
Therefore, a careful review of the terms of their cloud services contracts by all cloud service clients is strongly recommended. It also goes without saying that as a result of Article 28 of the Regulations, cloud providers used to operating under their standard terms, will in future be required to display a greater degree of flexibility when negotiating contracts with prospective smaller clients.
Please contact us if you require legal advice or would like to find out more information about our services.
Blockchain or distributed ledger technology, has the power (its supporters say) to transform the processes traditionally used by banks, power supply companies and logistics providers to name but a few.
In fact, the technology is potentially suitable for any business process which operates in a pre-arranged, methodical and organised basis. Transacting in real estate and securities would be other good examples. It even has its uses in intellectual property as a method of verifying the authenticity and ownership of works of art, authorship, creation and design. From a data privacy perspective there is potential for application of blockchain technology to verify an individual’s identity, without the need to process that individual’s personal data.
The reported key benefits of blockchain technology include:
Despite these benefits, blockchain technology is still viewed with a mixture of caution, and interest by many regulators. Particularly sectoral regulators in the areas of data privacy and financial services. For example, when used as the underlying technology for processing bitcoin payments, the non-application of existing regulations such as the Electronic Money Directive and the Payment Services Directive (which only applies to "real" money such as banknotes and even electronic money as defined by the EMD) raises real consumer and business protection concerns.
From a data privacy perspective, it is not always clear whether the distributed nature of blockchain servers/nodes across multiple jurisdictions, enables or facilitates compliance with international personal data transfer requirements under GDPR and related data privacy legislation.
From a business technology perspective, any organisation considering utilising blockchain technology as a means of working with its customers and suppliers, will have to commission the development of systems be it with a blockchain development company or by sourcing “Blockchain-as-a-Service”.
In either case consideration needs to be given to the contracts entered into with the service providers to ensure that requirements are clearly identified and linked to a business goal, liability appropriately limited, privacy issues addressed and intellectual property position in terms of ownership agreed. As you can imagine these considerations will differ depending on whether an organisation sources to develop its own blockchain solution or utilises a cloud service.
In summary, as sexy as blockchain technology sounds with its many potential applications and ability to disrupt traditional business processes, organisations wishing to transition to blockchain technology should still consider the usual run-of-the-mill, but indescribably important contract, legal and regulatory matters forming part of any well-run IT transformation project.
Please contact us if you require legal advice or would like to find out more information about our services.