Commonly encountered issues in public sector ICT contracts

(This post is an extract from a wider chapter on Public Sector ICT Procurement, prepared for an NZLS CLE Technology Law Conference in June and August 2013.)

Can I use a regular commercial contract for public sector ICT purposes? Do public sector ICT contracts differ from ICT contracts between private sector entities and, if so, in what respects? And what can we, as lawyers working on ICT contracts – whether for public or private sector clients – do to make negotiation and uptake more efficient? These are the questions I seek to address in this post.

Can I use a regular commercial contract for public sector ICT purposes?

For many, this is a rhetorical question, the perhaps obvious answer to which is “usually not, no, at least not without some significant amendment”. As such, it’s not a question to dwell on. It is a question worth addressing, though, because if you’re new to ICT transactions, this is the kind of question you should be asking. If you don’t, you might use a bog standard commercial services template in a situation for which it is ill-suited.

Those who subscribe to contract opportunities on the Government Electronic Tenders Service (GETS) will likely have seen examples of this. I have. The consequences can include insufficient warranty and indemnity protection, the absence of acceptance testing and software-related provisions, inadequate treatment of potentially complex intellectual property issues (including open source issues), insufficient security controls and data/privacy protection, a lack of sufficient disengagement provisions and unwitting disregard of government policy requirements, expectations and norms.

Do public sector ICT contracts differ from ICT contracts between private sector entities?

They can do, yes, and in several respects. The list below provides examples of the kinds of provisions commonly found in government ICT contracts, for which there may be weaker or no purely private sector equivalent; the list is not intended to be exhaustive:

  • data sovereignty: strong so-called “data sovereignty” provisions that prevent export of data overseas (even for processing and return) without the agency’s prior written consent and even then only in specific jurisdictions (often qualified by recognition that Internet traffic routing may be international and therefore permitted but subject to stated security requirements such as encryption);
  • privacy: strong privacy-related provisions that enable the agency to comply with the Privacy Commissioner’s Privacy Breach Guidelines in the event of a privacy breach by the service provider that relates to personal information for which the agency is responsible;
  • indemnities: indemnity coverage that may exceed private sector norms and in circumstances where there are no corresponding indemnities from the agency to the service provider given restrictions on the granting of indemnities in the Public Finance Act 1989;
  • security standards: requirements for compliance with government security standards, such as the New Zealand Information Security Manual and the Security in the Government Sector manual or other Australasian or international standards;
  • security testing rights: provisions entitling the agency (or Lead Agency in a syndicated or common capability context) to have access to the service provider’s testing reports and to undertake the agency’s own penetration, stress or other security testing for the purposes of identifying whether there are any vulnerabilities or defects or providing assurance as to the security of a system or services;
  • intellectual property: intellectual property provisions that adopt recommendations in the Guidelines for Treatment of Intellectual Property Rights in ICT Contracts, frequently conferring ownership of new IP on the service provider with broad licences back to the contracting agency and other agencies;
  • open source: open source provisions that:
    • require agency consent before open source software is used (the aim not being to prevent the use of such software but to give the agency the right to approve its use as well as to enable the agency to be aware of and comply with the applicable open source licence terms);
    • modify (soften) the application of certain warranty and indemnity provisions where open source software is used; and
    • allow the service provider to own the IP in adaptations to or derivatives of open source software but require it to comply with the open source licence terms and, on agency request, release the adaptations or derivatives to one or more specified open source software repositories;
  • syndication / common capability provisions: in syndicated and common capability contracts, syndication and common capability provisions that deal with uptake by other agencies, promotion of the syndicated or common capability services by the service provider, action by the Lead Agency on behalf of other agencies, Lead Agency administration fees, and cross-agency governance;
  • confidentiality: confidentiality provisions that:
    • permit disclosure of the agreement to other agencies;
    • permit disclosure as required under the Official Information Act or by Ministers or Parliament, subject sometimes to prior notification or consultation obligations;
    • permit open publication of the agreement (sometimes subject to redaction of commercially sensitive information);
  • tax and security checks: provisions that authorise the agency to undertake tax and security checks on service provider staff and that require the service provider to take whatever steps are necessary to enable this to occur;
  • liability: liability provisions that:
    • in shared services contexts (where one agency contracts with the service provider for the build of a shared government service), deem loss suffered by other agencies to be loss caused by the contracting agency and to be recoverable by that agency vis-à-vis the service provider;
    • contain categories of deemed direct loss that may exceed the norm in purely private contexts;
  • agency-specific requirements: provisions required by specific agencies given their legislative operating environments, eg, certificates of secrecy;
  • Web Standards: for contracts that involve the development of public facing websites, compliance with the mandatory requirements of the New Zealand Government Web Standards;
  • record keeping: provisions that facilitate agency compliance with the Public Records Act 2005;
  • pricing: most preferred customer pricing provisions (whilst not unique to public sector ICT contracts, they might be more common in that context);
  • reporting: comparatively detailed reporting requirements, eg, market / technology developments reporting;
  • step-in: provisions enabling the agency itself, or via another service provider, to step and assume control in the event of service provider default (again, whilst not unique to public sector ICT contracts, they might be more common in that context and, given recent events, may assume greater prominence in some areas in future).

What can government and other ICT lawyers do to better facilitate public sector ICT contracting?

The development of ICT contracts can be a time-consuming and costly process for agencies. There are many capable lawyers both within and otherwise serving government in this space. There are also many high quality ICT contracts in and entering circulation across government, many of which are evolving over time, and it would be fickle to suggest that both in-house counsel and firms don’t leverage some of the learnings and drafting they see in others’ contracts, a reality which is facilitated by both GETS and operation of the External Legal Services Panel.

Some of these contracts have been converted to templates and (presumably) made available for re-use on the Government Legal Network shared intranet.

The fact remains, however, that the positions they contain in commonly debated and negotiated areas (warranties, indemnities, liability, direct/indirect loss, insurance levels, audit and intellectual property, to name a few) often differ, sometimes substantially. Sometimes the differences reflect individual lawyers’ and firms’ approaches, sometimes they reflect clients’ opening positions that are not resisted and sometimes they reflect more balanced opening positions drafted in the light of accumulated experience. In addition, agencies that don’t deal with ICT contracts frequently may not be aware of these contracts and may prepare documents that do not cover off relevant government-related risks and expectations.

The key point is that there are few universally accepted standards, meaning there is less consistency than there could be which, in turn, may generate greater transaction costs for both agencies and suppliers through repeated negotiation of the usual suspects and less than optimal project delivery times.

Some overseas governments have sought to address this issue. The UK Government developed model ICT templates and an associated negotiating guide, whilst a number of Australian states have developed standard ICT templates and guidance.
In New Zealand, a public sector ICT Templates project was commenced a number of years ago and was making good progress, but the project was stopped for reasons that are unclear.

Query whether the time has come to renew the idea of standard New Zealand government ICT templates across a range of core areas, with cross-agency governance and substantial consultative input from both a cross-section of agencies and the New Zealand ICT industry. This is not to suggest that the templates would be fit for purpose for every conceivable occasion but – with accompanying policy guidance – they ought to be able to foster greater consistency, short-cut the drafting process, reduce transaction costs, reduce project delivery times, and reduce risk.

Such an initiative is unlikely to happen without the active support of ICT lawyers, in-house and external, that advise the public sector and the ICT industry. Are we willing to put our hands up?

There would, naturally, need to be a lead agency. Given that the GCIO is the Functional Leader for ICT, DIA would seem to be the obvious choice, with backup from the likes of MBIE, the Treasury, SSC, MPI, IRD and MSD.

Funding would, of course, be an issue, particularly in the current economic climate. It is here that I raise the prospect – completely independently and for open debate – of industry funding or co-funding for the project. Given that the ICT templates would benefit both agencies and suppliers and given at least the possibility that suppliers may secure more favourable positions in certain areas, arguably the New Zealand ICT industry has a vested interest in their creation.

Crowd-funding anyone?

View All

Leave a Reply