United States: White Paper: Recent Department Of Defense Guidance On Cybersecurity Requirements And Related Export Control Issues


The U.S. Department of Defense (DoD) recently issued two sets of guidance regarding Defense Federal Acquisition Regulation Supplement (DFARS) Clause 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting" (the -7012 Clause). The most recent guidance was attached to an April 24, 2018 notice and request for comment titled "DoD Guidance for Reviewing System Security Plans and the NIST SP 800-171 Security Requirements Not Yet Implemented." 83 Fed. Reg. 17,807 (the April 24 Guidance). The second set of guidance consists of updated Frequently Asked Questions that DoD issued on April 2, 2018 (the Updated FAQs). This White Paper examines the impact of the April 24 Guidance and the Updated FAQs on the role of contractor System Security Plans (SSPs) and Plans of Action and Milestones (POAMs) in source selection and contract performance, the proper interpretation of particular National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 requirements, and the potential impact of the -7012 Clause safeguarding and reporting requirements on export-controlled information resident in contractor information systems.

1. Evaluation of SSPs and POAMs During Source Selection and Contract Performance

As we previously explained in this post, the -7012 Clause requires contractors to provide "adequate security" for covered defense information (CDI) when it is stored, processed or transmitted by information systems operated by, or on behalf of, the contractor or when performance of the DoD contract involves operationally critical support. The -7012 Clause states that adequate security requires, at a minimum, that information systems on which CDI is processed, stored, or transmitted comply with the security requirements of NIST SP 800-171. Contractors subject to the -7012 Clause are required to flow that clause down to subcontractors at all tiers, with the exception of Commercial Off the Shelf (COTS) item subcontractors, that have, or will have, CDI on their information systems or that will perform operationally critical support.

NIST SP 800-171 Requirement 3.12.4 requires the organization to "[d]evelop, document, and periodically update [SSPs] that describe system boundaries, system requirements of operation, how security requirements are implemented, and the relationships with or connections to other systems." DoD expects SSPs to describe how the NIST SP 800-171 security requirements are met or how the contractor plans to meet any security requirements that have not been met. In addition, NIST SP 800-171 requires organizations to develop and implement POAMs that are designed "to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems." DoD expects POAMs to describe how any unimplemented security requirements will be met and how any unmet requirements or requirements with identified deficiencies will be mitigated.

Previous DoD guidance stated that procuring agencies were authorized to request and evaluate offerors' SSPs and POAMs in the course of making procurement decisions. The April 24 Guidance provides more detail on the use of SSPs and POAMs in that regard and in monitoring contract performance after a contract is awarded.

The April 24 Guidance includes a draft document titled "DoD Guidance for Reviewing System Security Plans and the NIST SP 800-171 Security Requirements Not Yet Implemented." This document is intended to facilitate agencies' review and understanding of the risks that any offeror's or contractor's failure to meet a particular security requirement may have on the offeror's or contractor's information system, and to assist in prioritizing the implementation of security requirements not yet implemented. To that end, the draft document establishes "DoD value" metrics that assign priority rankings to each security requirement. These rankings, like the NIST SP 800-171 requirements themselves, are based upon the security requirements of NIST SP 800-53 and range from 1 to 5, with 1 representing the lowest impact on an information system and thus being of the lowest priority for implementation. The draft document cautions that these metrics are "not to be used to assess implemented security requirements, nor to compare or score a company's approach to implementing a security requirement."

The draft document is accompanied by a matrix titled "Assessing the State of a Contractor's Internal Information System in a Procurement Action." This matrix illustrates various ways in which DoD may assess SSPs and POAMs in the course of source selection decisions and contract performance. The matrix is structured around four "objectives": (1) evaluation or assessment of a contractor's implementation of NIST SP 800-171 at the time of source selection; (2) evaluation of protections implemented by a contractor that go beyond the NIST SP 800-171 security requirements at the time of source selection; (3) assessment of implementation of NIST SP 800-171 requirements after contract award and monitoring of compliance with the requirements; and (4) confirmation of a contractor's self-certification with the -7012 Clause and NIST SP 800-171. Each objective is accompanied by clauses and additional information that the source selection authority must include in a solicitation or Request for Proposals, an explanation of how the source selection authority should evaluate an offeror's compliance with specific requirements, and clauses and documents that must be included or incorporated in any contract that is awarded.

The April 24 Guidance presents many practical challenges for offerors. To begin with, the new guidance will impact how offerors draft and compile information for their proposals. Offerors will need to ensure that their SSPs and POAMs are accurate, complete and proposal-ready. Furthermore, offerors may have to obtain SSPs and POAMs from teaming members and other proposed subcontractors for proposal submission. To the extent that teaming partners or potential subcontractors even have SSPs or POAMs, they are likely to regard them as proprietary and confidential and will want to limit their distribution. Second, they may be hesitant to share their SSPs and POAMs with the offeror or the government out of concern that these documents would reveal weaknesses in their systems or create compliance issues. Finally, team partners or potential subcontractors may be concerned that the offeror might use their SSPs and POAMs to its advantage in a later procurement where the teaming partners or potential subcontractors are the offeror's competitors. Each of these concerns would likely be heightened in the case of foreign teaming partners and suppliers and potential subcontractors that are small or medium-sized businesses.

The April 24 Guidance is also likely to serve as a basis for bid protests, particularly in the short term as DoD source selection authorities grapple with how best to implement it. In the pre-award phase, an offeror may have the opportunity to protest if it believes that the terms of a solicitation are contrary to the guidance. Post-award, a disappointed offeror may have the opportunity to protest the agency's evaluation of SSPs and POAMs. Another potential issue for post-award protests is the disclosure of SSPs and POAMs in the administrative record to the extent that they constitute or contain CDI. For example, it is unclear exactly what CDI safeguarding requirements would apply to a law firm representing a protesting party in order to receive copies of the awardee's SSP or POAMs. To date, we have not seen any guidance from the Government Accountability Office on this issue.

Finally, the fact that the April 24 Guidance requires SSPs and POAMs to be assessed in connection with the award of a DoD contract means that a contractor could face allegations of potential "fraudulent inducement" False Claims Act liability if its proposal misrepresents its current compliance with security requirements and/or its intentions or plans with respect to unmet security requirements. Of course, under Universal Health Services, Inc. v. United States ex rel. Escobar, 136 S. Ct. 1989 (2016), the U.S. Department of Justice or a qui tam relator would have to show that the offeror's false or misleading representations about its compliance with security requirements were material to the agency's decision to award the contract to the offeror.

Comments on the April 24 Guidance are due by May 31, 2018.

2. NIST Security Requirements Addressed/Altered in Updated FAQs

The following discussion is intended to serve as a high-level summary of some of the most significant changes and revisions reflected in the Updated FAQs.

a. SSPs/Compliance with NIST SP 800-171

As something of a corollary to the April 24 Guidance discussed above, the Updated FAQs discuss SSPs and POAMs and their role in contractor selection and contract administration. DoD's response to FAQ 53 states that SSPs "provide[] a mechanism to address, as part of the requiring activities overall risk management decision, situations in which all of the NIST SP 800-171 security requirements are not fully implemented on the covered contractor's information system." DoD's response to FAQ 91 states that "requiring activities may utilize the [SSPs] and associated [POAMs] in a variety of ways in the contract formation/administration process in order to obtain the level of security that they require." Response to FAQ 91 goes on to establish that these include, but are not limited to:

  • Require that proposals identify any NIST SP 800-171 security requirements not implemented at the time of award and include associated plans of action for implementation. Implementation of NIST SP 800-171, as documented in the [SSP] or otherwise, would be considered as part of the source selection process. Proposal instructions and corresponding evaluation specifics of how implementation of NIST SP 800-171 will be used by the DoD to determine whether or not it is acceptable or unacceptable to process, store, or transmit covered defense information on a system hosted by the offeror must be detailed in sections L and M of the solicitation as well as the Source Selection Plan. This scenario is outside of the scope of [the -7012 Clause].
  • Identify in the solicitation that all security requirements in NIST SP 800-171 must be implemented at the time of award. Planned or partial implementations would generally not be allowed, with the exception of any enduring exceptions to the requirements to accommodate special circumstances (e.g., medical devices), or any individual, isolated or temporary deficiencies. This scenario is outside of the scope of [the -7012 Clause].
  • The Updated FAQs also touch on Federal Risk and Authorization Management Program (FedRAMP) equivalency and certification for cloud providers. The response to FAQ 105 explains that the -7012 Clause does not mandate that a contractor use a cloud services provider that is specifically FedRAMP approved; rather, the -7012 Clause requires a contractor to ensure that the cloud services provided meet those same requirements. With respect to the requirement that cloud services be at least equivalent to "FedRAMP moderate" standards versus NIST SP 800-171 standards, the Updated FAQs suggest that implementation of NIST SP 800-171 (which allows for planned implementation of some requirements if documented in the [SSP] and associated plans of action), by signing the contract at the time of award. No additional conditions beyond [the -7012 Clause] are imposed.

DoD's response to FAQ 50 states that DoD requiring activities "should restrict their security requirements to [the -7012 Clause] and NIST SP 800-171 unless there is a specific need to increase security above the 'Moderate' impact level." If the DoD requiring activity expects full implementation of all NIST SP 800-171 requirements at the time of contract award, it should specifically identify such requirement in the solicitation. See Response to FAQ 53. Furthermore, if an offeror meets the requirements of NIST SP 800-171, the DoD requiring activity should not use the evaluation/source selection process to define the acceptability of how the contractor meets those requirements. See Response to FAQ 55.

FAQ 92 asks whether there is a "prescribed format/level of specificity" for an SSP. DoD's response states:

No. Footnote 26 to NIST SP 800-171 Security Requirement 3.12.4 states that, "There is no prescribed format or specified level of detail for system security plans. However, organizations must ensure that the required information in 3.12.4 is appropriately conveyed in those plans." Additionally, Chapter 3 of NIST SP 800-171, Revision 1 states that, "Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format."

Similarly, DoD's response to FAQ 50 states that DoD components "should not intrude into the operations or management of the contractor's internal IT system by specifying the content and format of the system security plans and plans of action that address deficiencies, requiring any specific method for validating and assessing the system, or specifying the parameters of security requirements."

Finally, DoD's response to FAQ 18 states that, in circumstances where SSPs and POAMs are used to assess the risks in awarding a contract to a particular company, the agency may include in the contract a provision to review the company's progress in implementing its POAMs.

b. Significant NIST Requirements Addressed in the Updated FAQs

The Updated FAQs provide further insight into DoD's interpretation of the well-known NIST 800-171 requirement for multifactor authentication, Requirement 3.5.3. For example, DoD edited the response to FAQ 74 (formerly numbered FAQ 41) to set forth definitions of "Local Access," "Network Access" and "Non-Privileged User." The responses to FAQs 74 and 77 also clarify that, except under certain circumstances, multifactor authentication is not required to access mobile devices like smartphones or tablets, even if those devices contain CDI (although CDI on mobile devices must be encrypted and the encryption module Federal Information Processing Standard (FIPS)-validated, see FAQ 78). However, if the mobile device is used to access a contractor information system containing CDI, the system has to provide the capability for multifactor authentication for access by the device, which would be entered via the device (e.g., use of a one-time password device).

The Updated FAQs also provide additional information relating to encryption, another significant NIST security requirement. For example, the response to FAQ 98 clarifies that, with respect to controlled unclassified information (CUI) that is at rest in any nonmobile device or data center and protected by other logical or physical methods, encryption is an option, but not a requirement.

FAQ 68 addresses the NIST security requirements regarding FIPS-validated cryptography and whether it is sufficient if the algorithm is FIPS approved. DoD's response states that:

Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140. When an application or device allows a choice (by selecting FIPS-mode or not), then the FIPS-mode has been validated under FIPS 140-2, but the other options (non-FIPS) allow certain operations that would not meet the FIPS requirements. More information is available at [http://csrc.nist.gov/groups/STM/cmvp/] and [http://csrc.nist.gov/groups/STM/cmvp/validation.html].

FAQ 94 asks whether encryption is required by NIST Requirement 3.13.8 "for a Multiprotocol Label Switching (MPLS) private network (thus an extension of a local network) [that] is multi-tenant protected by [virtual LANS]." DoD's response states that "encryption, though preferred, is not required if using common-carrier provided MPLS, as the MPLS separation provides sufficient protection without encryption."

FAQ 95 asks whether Transport Layer Security (TLS) can be used to protect CDI during transmission over the Internet. DoD's response states that:

Yes, TLS can be used. The current version of TLS (TLS 1.2) is preferred. If earlier versions must be used to interact with certain organizations, the servers shall not support Secure Sockets Layer (SSL) version 3.0 or earlier. The cryptographic module used by the server and client must be a FIPS 140-validated cryptographic module. All cryptographic algorithms that are included in the configured cipher suites must be within the scope of the validation, as well as the random number generator. For further information see NIST SP 800-52, Rev 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, April 2014.

Finally, with respect to the marking of media with CUI markings and distribution limitations per NIST SP 800-171 Requirement 3.8.4, DoD's response to FAQ 86 clarifies that this requirement only applies to CDI and that it does not apply to information provided by, or developed for, non-DoD organizations. It further states that "guidance on marking media, along with other materials, should be addressed separately in the contract and is derived from DoD Manual 5200.01, Volume 4, DoD Information Security Program: Controlled Unclassified Information (CUI)."

c. Cloud Computing-Specific Updated FAQs

The Updated FAQs also touch on Federal Risk and Authorization Management Program (FedRAMP) equivalency and certification for cloud providers. The response to FAQ 105 explains that the -7012 Clause does not mandate that a contractor use a cloud services provider that is specifically FedRAMP approved; rather, the -7012 Clause requires a contractor to ensure that the cloud services provided meet those same requirements. With respect to the requirement that cloud services be at least equivalent to "FedRAMP moderate" standards versus NIST SP 800-171 standards, the Updated FAQs suggest that DoD implemented that requirement because it does not believe that the NIST standards go far enough in securing information stored in the cloud. Instead, DoD requires compliance with FedRAMP moderate standards because they were developed with those additional security measures in mind. The Updated FAQs also note that FedRAMP moderate-level cloud services are well-established and offered by many providers, implying that DoD believes that a contractor should not have difficulty securing services that meet those requirements.

3. Potential Implications of Updated FAQs for ITAR- and EAR-Controlled Information

Among the Updated FAQs are FAQs 25 and 26, which contain important applications of the -7012 Clause to certain export controlled-information—as described in the CUI registry1

4. Conclusion

and incorporated into the definition of CDI—and systems that store, transmit or process it. Specifically, these FAQs state, without qualification, that export-controlled information that is "collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of [a DoD] contract" qualifies as CDI and must be protected accordingly. As explained below, this interpretation carries potentially broad implications for companies who use pre-existing technical data or technology in the course of their performance on a DoD contract, as well as for foreign suppliers or subcontractors who may possess such data outside the context of a DoD contract or subcontract.

U.S. export control laws generally include the International Traffic in Arms Regulations (ITAR), 22 C.F.R. §§ 120–130, administered by the Department of State's Directorate of Defense Trade Controls (DDTC), and the Export Administration Regulations (EAR), 15 C.F.R. §§ 730–774, administered by the Department of Commerce's Bureau of Industry and Security (BIS). Broadly speaking, these regulations prohibit the movement or provision of controlled goods and services outside the United States and to unauthorized non-U.S. persons. In addition, the regulations control the flow of data and information (i.e., "technical data" under the ITAR and "technology" under the EAR) associated with such goods and services. Finally, these regimes prohibit the "release" of information (i.e., through visual or other inspection by, or an oral or written exchange with, unauthorized foreign persons in the United States or abroad).

Although access controls and other information security principles are unquestionably fundamental to ITAR and EAR compliance, neither framework mandates (with some exceptions for cloud computing) specific security standards such as those prescribed by the -7012 Clause. More importantly, the ITAR and EAR do not impose affirmative obligations to report mere network intrusions, absent a triggering export or other release of information. See, e.g., 22 C.F.R. § 126.1(e)(1) (mandating DDTC notification in the event that ITAR-controlled data is exported to certain export-prohibited countries). It is against this backdrop that the clarifications in FAQs 25 and 26 are especially significant.

FAQs 25 and 26 generally address the interrelationship of export-controlled technical data and technology with CDI. FAQ 25 provides that export controlled information is considered CDI when it is either (1) marked as such and provided to the contractor by or on behalf of DoD or (2) "collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the [DoD] contract." FAQ 25 goes on to say that "when DoD contractors hold information that is export controlled and that is related to the DoD activity in performance of the contract, the information requires safeguarding."

DoD pronouncements prior to FAQ 25 noted that not all contractor information that was "used" by the contractor in support of the performance of a DoD contract constitutes CDI. Such information includes "information in the contractor's human resources or financial/accounting systems," which DoD apparently views as incidental to performance of a particular contract. Drawing on this example, pre-existing export controlled data residing on a contractor's information system could also reasonably be regarded as incidental to performance of a particular DoD contract. Therefore, even if the contractor used pre-existing export controlled information in support of its performance of a DoD contract, that information would not thereby become CDI. However, FAQ 25 makes no reference to any exception when it comes to export-controlled information. Rather, it states that, "[w]hen DoD contractors hold information that is export controlled and is related to the DoD activity in performance of the contract, the information requires safeguarding" — period. This stands in contrast to the language in DoD's response to FAQ 29, which notes that information in the contractor's human resources or financial/accounting is not considered CDI even if it is used by the contractor to support contract performance.

Furthermore, while FAQ 26 explains that the DFARS safeguarding clause "only applies to export controlled information that meets the definition of covered defense information," it goes on to state that the -7012 Clause "requires the contractor to provide adequate security on the information systems that process, store, or transmit covered defense information" (emphasis added). Thus, although the -7012 Clause "does not assign any specific safeguarding requirements to the [export controlled] information itself," the practical implication is an extension of the -7012 Clause to information systems that may not otherwise be involved in the performance of the DoD contract or safeguarded in accordance with the -7012 Clause.

Granted, companies who are already compliant with the -7012 Clause on a company-wide basis (e.g., on account of their frequent engagement in DoD contracts or handling of export-controlled information) or who can effectively segment and isolate CDI-classified, export-controlled information that is newly developed for a particular contract would be able to avoid or manage significant disruption from this extension of the -7012 Clause. More commonly, however, export-controlled information predates its use in the performance of a DoD contract and may exist on information systems that are wholly unrelated to DoD contract performance. For example, export-controlled data might be shared pursuant to a manufacturing license agreement unrelated to a DoD contract and then later classified as CDI based on its use in a subsequent DoD contract in the United States. Such use could arguably trigger the -7012 Clause safeguard requirements for the data and for the entire system on which it resides.2

In many cases, implementation of the -7012 Clause safeguards will overlap with controls and preparations undertaken in the context of technology control plans developed pursuant to, e.g., 22 C.F.R. § 126.13(c). Moreover, companies employing EAR-compliant cloud services will also be familiar with various NIST encryption and access control standards involved in the deployment of those services. See 15 C.F.R. § 734.18(a)(5)(iii). That said, the substantial breadth of the -7012 Clause and NIST SP 800-171 will inevitably involve careful scrutiny and resource allocations to ensure compliance with these more comprehensive standards.

More importantly, the -7012 Clause also imposes cyber incident reporting requirements that are more stringent than those imposed by export control regulations. BIS, for example, has specifically noted that data breach victims do not engage in illicit exports simply because they experience a breach. See 81 Fed. Reg. 35,568, 35,592 (June 3, 2016) ("This provision [i.e., 15 C.F.R. § 734.15, defining "Release"] codifies the basic concept that the unwitting victim of, for example, a database hack is not the one responsible for the theft of technology."). And, notwithstanding the mandatory reporting required under ITAR's Section 121.1(e)(1), absent evidence of exfiltration or release of controlled information, neither ITAR nor EAR imposes general obligations to report mere network breaches. By contrast, the -7012 Clause requires reporting of a far broader range of cyber incidents, i.e., any "compromise or an actual or potentially adverse effect on an information system and/or the information residing therein" within 72 hours after its discovery.

Against that backdrop, the extension of the -7012 Clause to systems on account of their contact with export-controlled information that has been identified as CDI could generate significant technical and compliance challenges for companies operating in the export controls space. As a technical matter, adequate safeguarding, specifically intrusion detection and breach reporting, implicates a wider array of technical capabilities and resources compared to access controls and encryption implementations involved in technology control plans—a distinction that will warrant, among other considerations, close attention to the scope of services contracts with information security vendors. On the compliance front, network penetration reporting requirements will inevitably increase the pressure on companies reporting breaches to the DoD to consider concurrent voluntary disclosures to DDTC and BIS.

In addition to these internal considerations, the application of -7012 to pre-existing information used in DoD contracts also implicates contractual relationships with foreign recipients (future and past) of export controlled information, such as in the context of technical assistance or manufacturing license agreements authorized by DDTC. Companies that have provided, or intend to provide, export controlled information that has been or will be used in a DoD contract (particularly where the foreign recipient is not involved in the DoD contract) must take care to draft and enforce contractual obligations that provide for compliance with -7012 and NIST SP 800-171—an effort complicated by DOD's ongoing negotiations with countries whose laws prohibit the types of reporting required by -7012. See Response to FAQ 9.

4. Conclusion

The enactment of the -7012 Clause and related draft DoD guidance are just the latest steps with regard to a continuing cycle of cybersecurity framework developments. This DFARS provision and the guidance both provide clarification for contractors with regard to their responsibilities and raise the specter of increased regulatory burdens beyond those already mandated under existing frameworks (e.g., ISO 27001, FedRAMP). What is clear is that DoD's approach to implementing these provisions and its overall cybersecurity framework will continue to evolve in the coming months and years.

Covered contractors will have to balance keeping up with DoD's efforts in this area with their efforts to comply with additional frameworks currently under development, both at home and abroad. In the European Union (EU), in particular, contractors will have to contend with a complex web of cybersecurity and privacy regulations, some of which are in harmony with the DFARS, while others go far beyond DoD's actions to this point. The EU's General Data Protection Regulation (GDPR) and Cybersecurity Directive are both taking effect this year and are poised to become the gold standard in privacy and cybersecurity measures. Flashpoints between DoD and GDPR provisions are bound to arise. For example, given the broad categories of information that constitute CDI and CUI under the -7012 Clause, the GDPR's mandates related to data access, rectification, deletion and modification may clash with existing ITAR and EAR compliance regimes. Developments in the EU will also require a more careful analysis of contractor and subcontractor data retention and processing policies and procedures.

These developments are just the beginning. Covered defense contractors, particularly those who fall within the terms of EU regulations, will have to increasingly parse and balance intersecting, sometimes contradictory, frameworks related to cybersecurity and privacy. What is more, it likely will not be long before the government imposes requirements similar to the -7012 Clause on all federal government contractors through the Federal Acquisition Regulation. We will further explore some of these themes in our upcoming post examining new EU regulations from the perspective of U.S. covered defense contractors.


1 The CUI registry describes "export controlled" information as:Unclassified information concerning certain items, commodities, technology, software, or other information whose export could reasonably be expected to adversely affect the United States national security and nonproliferation objectives. To include dual use items; items identified in export administration regulations, international traffic in arms regulations and the munitions list; license applications; and sensitive nuclear technology information.

2 This would not be the case if the pre-existing export-controlled data pertained to a "commercial item." See Response to FAQ 2. Pursuant to the Response to FAQ 2, only documents or data describing a substantive change to the commercial item or its use or integration within DoD or a DoD system or platform require protection as CDI, "not the standard commercial item itself or associated data."

To print this article, all you need is to be registered on Mondaq.com.

Click to Login as an existing user or Register so you can print this article.

Similar Articles
Relevancy Powered by MondaqAI
In association with
Related Topics
Similar Articles
Relevancy Powered by MondaqAI
Related Articles
Up-coming Events Search
Font Size:
Mondaq on Twitter
Mondaq Free Registration
Gain access to Mondaq global archive of over 375,000 articles covering 200 countries with a personalised News Alert and automatic login on this device.
Mondaq News Alert (some suggested topics and region)
Select Topics
Registration (please scroll down to set your data preferences)

Mondaq Ltd requires you to register and provide information that personally identifies you, including your content preferences, for three primary purposes (full details of Mondaq’s use of your personal data can be found in our Privacy and Cookies Notice):

  • To allow you to personalize the Mondaq websites you are visiting to show content ("Content") relevant to your interests.
  • To enable features such as password reminder, news alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
  • To produce demographic feedback for our content providers ("Contributors") who contribute Content for free for your use.

Mondaq hopes that our registered users will support us in maintaining our free to view business model by consenting to our use of your personal data as described below.

Mondaq has a "free to view" business model. Our services are paid for by Contributors in exchange for Mondaq providing them with access to information about who accesses their content. Once personal data is transferred to our Contributors they become a data controller of this personal data. They use it to measure the response that their articles are receiving, as a form of market research. They may also use it to provide Mondaq users with information about their products and services.

Details of each Contributor to which your personal data will be transferred is clearly stated within the Content that you access. For full details of how this Contributor will use your personal data, you should review the Contributor’s own Privacy Notice.

Please indicate your preference below:

Yes, I am happy to support Mondaq in maintaining its free to view business model by agreeing to allow Mondaq to share my personal data with Contributors whose Content I access
No, I do not want Mondaq to share my personal data with Contributors

Also please let us know whether you are happy to receive communications promoting products and services offered by Mondaq:

Yes, I am happy to received promotional communications from Mondaq
No, please do not send me promotional communications from Mondaq
Terms & Conditions

Mondaq.com (the Website) is owned and managed by Mondaq Ltd (Mondaq). Mondaq grants you a non-exclusive, revocable licence to access the Website and associated services, such as the Mondaq News Alerts (Services), subject to and in consideration of your compliance with the following terms and conditions of use (Terms). Your use of the Website and/or Services constitutes your agreement to the Terms. Mondaq may terminate your use of the Website and Services if you are in breach of these Terms or if Mondaq decides to terminate the licence granted hereunder for any reason whatsoever.

Use of www.mondaq.com

To Use Mondaq.com you must be: eighteen (18) years old or over; legally capable of entering into binding contracts; and not in any way prohibited by the applicable law to enter into these Terms in the jurisdiction which you are currently located.

You may use the Website as an unregistered user, however, you are required to register as a user if you wish to read the full text of the Content or to receive the Services.

You may not modify, publish, transmit, transfer or sell, reproduce, create derivative works from, distribute, perform, link, display, or in any way exploit any of the Content, in whole or in part, except as expressly permitted in these Terms or with the prior written consent of Mondaq. You may not use electronic or other means to extract details or information from the Content. Nor shall you extract information about users or Contributors in order to offer them any services or products.

In your use of the Website and/or Services you shall: comply with all applicable laws, regulations, directives and legislations which apply to your Use of the Website and/or Services in whatever country you are physically located including without limitation any and all consumer law, export control laws and regulations; provide to us true, correct and accurate information and promptly inform us in the event that any information that you have provided to us changes or becomes inaccurate; notify Mondaq immediately of any circumstances where you have reason to believe that any Intellectual Property Rights or any other rights of any third party may have been infringed; co-operate with reasonable security or other checks or requests for information made by Mondaq from time to time; and at all times be fully liable for the breach of any of these Terms by a third party using your login details to access the Website and/or Services

however, you shall not: do anything likely to impair, interfere with or damage or cause harm or distress to any persons, or the network; do anything that will infringe any Intellectual Property Rights or other rights of Mondaq or any third party; or use the Website, Services and/or Content otherwise than in accordance with these Terms; use any trade marks or service marks of Mondaq or the Contributors, or do anything which may be seen to take unfair advantage of the reputation and goodwill of Mondaq or the Contributors, or the Website, Services and/or Content.

Mondaq reserves the right, in its sole discretion, to take any action that it deems necessary and appropriate in the event it considers that there is a breach or threatened breach of the Terms.

Mondaq’s Rights and Obligations

Unless otherwise expressly set out to the contrary, nothing in these Terms shall serve to transfer from Mondaq to you, any Intellectual Property Rights owned by and/or licensed to Mondaq and all rights, title and interest in and to such Intellectual Property Rights will remain exclusively with Mondaq and/or its licensors.

Mondaq shall use its reasonable endeavours to make the Website and Services available to you at all times, but we cannot guarantee an uninterrupted and fault free service.

Mondaq reserves the right to make changes to the services and/or the Website or part thereof, from time to time, and we may add, remove, modify and/or vary any elements of features and functionalities of the Website or the services.

Mondaq also reserves the right from time to time to monitor your Use of the Website and/or services.


The Content is general information only. It is not intended to constitute legal advice or seek to be the complete and comprehensive statement of the law, nor is it intended to address your specific requirements or provide advice on which reliance should be placed. Mondaq and/or its Contributors and other suppliers make no representations about the suitability of the information contained in the Content for any purpose. All Content provided "as is" without warranty of any kind. Mondaq and/or its Contributors and other suppliers hereby exclude and disclaim all representations, warranties or guarantees with regard to the Content, including all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement. To the maximum extent permitted by law, Mondaq expressly excludes all representations, warranties, obligations, and liabilities arising out of or in connection with all Content. In no event shall Mondaq and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use of the Content or performance of Mondaq’s Services.


Mondaq may alter or amend these Terms by amending them on the Website. By continuing to Use the Services and/or the Website after such amendment, you will be deemed to have accepted any amendment to these Terms.

These Terms shall be governed by and construed in accordance with the laws of England and Wales and you irrevocably submit to the exclusive jurisdiction of the courts of England and Wales to settle any dispute which may arise out of or in connection with these Terms. If you live outside the United Kingdom, English law shall apply only to the extent that English law shall not deprive you of any legal protection accorded in accordance with the law of the place where you are habitually resident ("Local Law"). In the event English law deprives you of any legal protection which is accorded to you under Local Law, then these terms shall be governed by Local Law and any dispute or claim arising out of or in connection with these Terms shall be subject to the non-exclusive jurisdiction of the courts where you are habitually resident.

You may print and keep a copy of these Terms, which form the entire agreement between you and Mondaq and supersede any other communications or advertising in respect of the Service and/or the Website.

No delay in exercising or non-exercise by you and/or Mondaq of any of its rights under or in connection with these Terms shall operate as a waiver or release of each of your or Mondaq’s right. Rather, any such waiver or release must be specifically granted in writing signed by the party granting it.

If any part of these Terms is held unenforceable, that part shall be enforced to the maximum extent permissible so as to give effect to the intent of the parties, and the Terms shall continue in full force and effect.

Mondaq shall not incur any liability to you on account of any loss or damage resulting from any delay or failure to perform all or any part of these Terms if such delay or failure is caused, in whole or in part, by events, occurrences, or causes beyond the control of Mondaq. Such events, occurrences or causes will include, without limitation, acts of God, strikes, lockouts, server and network failure, riots, acts of war, earthquakes, fire and explosions.

By clicking Register you state you have read and agree to our Terms and Conditions