Date: Thu, 28 Mar 2024 10:15:52 +0000 (UTC) Message-ID: <1889224802.6079.1711620952789@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6078_476687531.1711620952787" ------=_Part_6078_476687531.1711620952787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Version 2.0: September = 2009
To provide sample proposal and contract language for common themes relat=
ed to data protection as well as practical guidance as to when and how to c=
onsider the themes when drafting or reviewing a request for information (RF=
I), request for proposal (RFP) or contract.
Top
The data security themes and sample contractual clauses are = provided for informational purposes only and are not to be construed as leg= al advice. The data security themes provided are issues for i= nstitutions of higher education to consider when drafting requests for info= rmation (RFI), requests for proposal (RFP), or contracts that might involve= institution data; however the themes are neither all-inclusive nor exhaust= ive, nor is every theme applicable to every RFI, RFP, or contract. In addit= ion, federal, state, and local laws and regulations may also have an impact= on data security provisions that should be included in a particular RFI, R= FP, or contract. Additionally, contract terms dealing with issues other tha= n information security may impact the effectiveness or enforceability of th= e suggested clauses in this document. The sample RFP requirements and quest= ions as well as contract clauses contained in this document should be seen = as a starting point for discussion and may need to be modified as appropria= te for the intended use.
For the foregoing reasons, it is essential that any intended use of the =
sample requirements and contractual clauses be reviewed by appropriate inst=
itutional legal counsel in the full context of the proposal requirements an=
d contractual arrangement prior to communication to the other contracting p=
arty and during negotiation of terms. Ultimately, the greatest concern shou=
ld be that the final negotiated result accurately reflects the intention of=
the parties and the reality of the situation.
Top
The following materials were used as the basis for this document.
NOTE: Sample RFP requirement questions and contractual clauses have been=
sanitized and identifying information related to a particular institution =
of higher education has been removed. In addition, while all of the referen=
ces provided by working group members were reviewed, the working group stop=
ped adding sample questions and clauses to this document once we accumulate=
d several samples for each theme (unless one of the references included a u=
nique wording or clause that was not already addressed). Institutions of hi=
gher education are encouraged to add their own sanitized sample questions a=
nd clauses as a way to make this document "living" following the uniqueness=
principle.
Top=
p>
Institutions of higher education function within a policy and regulatory= context uniquely their own. While regulatory frameworks such as the Health= Insurance Portability and Accountability Act (HIPAA), the Health Informati= on Technology for Economic and Clinical Health (HITECH) Act, the Gramm-Leac= h-Bliley Act (GLBA), the Payment Card Industry Data Security Standard (PCI = DSS), and state security breach notification laws belong to our common lexi= con, few among the growing body of third-party providers of information ser= vices to higher education are aware of FERPA or the rich tapestry of intern= al policies governing data access and distribution. Further, the seemingly = innocuous nature of many contemporary services (such as social networking) = has allowed companies to prosper merely by asserting rather than <= em>demonstrating strong security practices.
Conveying the appropriate information security requirements, eliciting m= eaningful and specific responses to those requirements, assessing potential= risks, and, utilizing the appropriate contractual clauses assist in framin= g the contracting party's role within your institution's regulatory context= . For example, by including a section that calls attention to FERPA and to = the fact that some of the data the contracting party will be handling quali= fies as part of a student's educational record, you ensure that the vendor = acknowledges that they will be operating within an environment where FERPA = considerations will inform their obligations.
This last point is made to underscore the need for an institution to ful= ly understand the nature and scope of the data it is protecting in any cont= ract. Ultimately, this will be the determining factor in choosing to includ= e any particular proposal requirement or contract language.
The challenge facing individuals responsible for drafting and reviewing =
RFPs and contracts for the purchase of information technology products and =
services - often individuals with job functions other than legal counsel - =
is, considering the nuances and particularities of each contract, knowing w=
hat clauses to include or look for in a contract and what clauses could be =
unnecessary or overburdening.
Top
The decision to include a specific contractual clause is contingent on f= our primary criteria:
Each of the themes listed below have been labeled as to criticality by t= he working group as appropriate for each rubric. Please note that every ins= titution will need to review these in light of their specific situation in = order to ensure alignment with local institutional policy and applicable la= ws and regulations.
Category 1: Ma= ndatory use in order to comply with Federal, State, or Agency regulations, = contains Personally Identifiable Information
Category 2: Ma= ndatory use in order to comply with institutional policies
Category 3: Re= commended use in order to comply with generally accepted best practices
Category 4: Re= commended to address common situational requirements
As a practical approach to address the aforementioned challenge, this do= cument divides the procurement of information technology products and servi= ces into three steps and organizes proposal and contractual language securi= ty themes around a decision tree consisting of four questions that an indiv= idual drafting or reviewing an RFP or contract should ask her/himself.
The basic idea is to consider each step and each question at a time in s=
equence and to select only those steps and themes that apply to the product=
or service being purchased and the data being protected. Nevertheless, as =
these processes are not necessarily linear, the individual may find a diffe=
rent approach worthwhile.
Top
Assuming that we already know "what" we are procuring and that = we are now concerned with the "from whom" we procure it, the procu= rement process for information technology products and services can be divi= ded into the following three general steps:
An RFP is an invitation for vendors to submit a proposal on a specific p= roduct or service. RFPs are usually designed to get vendors to provide a cr= eative solution to a business problem or requirement, bring structure to th= e procurement decision, and allow the risks and benefits of a solution to b= e identified clearly upfront. The creativity and level of detail that vendo= rs choose to include in their proposals should be used to = evaluate the quality of the vendors' proposals, their understanding of your= business and requirements, and as a means of comparison against each other= .
More often than not, institutions of higher education are very good at t= elling vendors what level of security is required or wanted in a product or= service but not as good or diligent in asking vendors to describe how they= propose to meet those requirements. Consequently, vendors need only to ass= ert rather than demonstrate strong security practices to meet evaluation cr= iteria. It is critical that the RFP conveys the appropriate information sec= urity requirements and elicits meaningful and specific responses that descr= ibe how the vendor will meet those requirements.
Consider the following when drafting or reviewing an RFP:
The Sample RFP Language provided in the themes below are intended to be = just that - examples and a memory-jogger to assist in identifying specific = items that may need to covered but are not.
As a practical approach to address the aforementioned challenge, this do= cument divides the procurement of information technology products and servi= ces into three steps and organizes proposal and contractual language securi= ty themes around a decision tree consisting of four questions that an indiv= idual drafting or reviewing an RFP or contract should ask her/himself.
The decision tree questions are:
Are there =
special conditions that I should consider? Am I missing something?
<=
/p>
A Word About Contract Monitoring
These days of outsourcing, software as a service, and cloud computing, i= nstitutions of higher education are increasingly turning to third-party ser= vice providers to maintain, manage, transmit, or store institution-owned in= formation resources to improve delivery of services, gain efficiencies, and= reduce cost. ISO/IEC 27002:2005, Reference 6.2.1 Identify Risks Relate= d to the Use of External Parties underscores that decision making and = action plans to address information security issues are to be "based on ris= k". In that regard, institutions of higher education are diligent in assess= ing the risk of critical information resources already in production but they are somewhat remiss at assessing and defining the incremental r= isk to the institution prior to engaging a third-party service pro= vider to host or provide a service on behalf of the institution.
To ensure that adequate security controls are in place prior to finalizi= ng any contract agreement, institutions - including their respective school= s, departments, clinics, and centers - engaging third-party service provide= rs to procure information technology services should conduct a third-party risk assessment for all services (applications, h= osting, systems, etc) that would involve the collection, processing= , transmission, or storage of Confidential or Sensitive data as defined by = the institutions' respective Data Classification Policy. Consider = the following when engaging third-party service providers to procure inform= ation technology services:
Resources:
Monitoring can mean different things to different people. For the purpos= e of this document, monitor means to assess, to watch, to keep track of, or= to check, usually, with a special purpose. It does not mean or imply to ve= rify or even to test. Actually, monitoring is more of a spectrum that range= s from just "keeping an eye" in the low end to requiring a site audit in th= e high end. Given the availability of resources at institutions of higher e= ducation, verification could be an impractical and significantly costly req= uirement if applied to all or most third-party contracts.
Effective contract monitoring requires a process or methodology in place= that defines the approach to take based on the risk of the contract or eng= agement - activities should be more stringent and closer to the high end of= the spectrum as risk increases or when exceptional situations warrant them= . Institutional policy may refer to instances in which the sharing of sensi= tive data will result in a significant risk. Again, "significant" can mean = a number of things but, ultimately, depends on the institution's risk manag= ement practices and risk tolerance (i.e., what is acceptable risk). Only in= cases of very high risk or when exceptional situations may warrant it shou= ld contract monitoring include a requirement to perform a site audit, of re= sults of a Statement on Standards for Attestati= on Engagements (SSAE) No. 16 (formerly SAS 70) audit, or of results of = an audit performed by an independent auditor.
Third, what should an institution do to monitor compliance with agreemen= t requirements in most cases? Again, let's focus on the Section's intent: D= efine the incremental risk to the institution when engaging third-party IT = service providers as well as defining a due diligence process for mitigatin= g those risks - third-party risk from remote access, data transmission and = offsite storage.
Consider the following as an outline for a contract monitoring process:<= /p>
For current signed contracts, assess their risk (if it has not already b= een done), and start with the steps listed in the Post Implementation secti= on above as needed.
It is important to keep in mind that contract monitoring is the last ste= p of a cascading progression. The initial identification of process and dat= a impacted as well as initial security requirements are used to formulate q= uestions for the RFP. The answers to the RFP are used to evaluate vendors a= nd refine the security requirements. The evaluation and risk assessment of = finalists refine the security requirements that will, in turn, be added as = language to the contract or statement of work. And, finally, it is the fina= l contract and corresponding risk level that determine the appropriate cont= ract monitoring approach.
Sample contract clauses are available for each of the following themes:<= /p>
Questions or= comments? Contact us.
Except wher= e otherwise noted, this work is licensed under a Creative Commons Attributi= on-NonCommercial-ShareAlike 4.0 International License (= CC BY-NC-SA 4.0).