Outsource Contracting Law, Policy, & Process Tracy Mitrano Ann Geyer Cornell University UC Berkeley
The Challenge of Cloud Computing The challenge of cloud computing revolves around the transition from a managed infrastructure and information to vendor products and services. Substantively, contracts bridge control of institutional information and business process. Procedurally, cloud computing requires rethinking the information technology organizational process from conception to implementation of a cloud service.
Contracting --Past, Present, and Future Pre Box Box Post Box Click Thru Nobody knows or cares Consortium Contract I2/Net+ intermediated Customized terms for HE Adhoc negotiation process Relationship contract Lessons learned Memorialize reliance components Create framework for management
Cloud Computing Operational Process
Cornell Box Policy http://www.it.cornell.edu/services/box/policy.cfm
Lessons Learned Janus face of cloud computing Contracts revisited Outsourcing Contract Process Contracts revisited Obsolescent linear process New vendor relationship Cloud computing & institutional missions Strategic planning Effectiveness & efficiencies Institutional integrity
Cloud Contract Objectives Recognize service and data control strategy is different University has diminished direct control Must rely on vendor policy, operations, and sub-vendors Recognize that the service environment is always changing Contract objectives Create a defined ongoing relationship Share risk and responsibilities Assign protection requirements Vendor—traditional asset protection University—focus on data and user protections Both—a comprehensive protection structure
Relationship Contract Concept Open Communications & Shared Decision-making Example provisions Ownership of data (IP) Right to use data (access, mining, indexing, etc.) Privacy and security protections Regulatory compliance Mediate differences Contract expiration
Other Contract Issues Common terms to protect the university Vendor may never unilaterally “share” data with 3rd party Frequent communication & notification by vendor Corrective action timeframes Indemnification for vendor errors Contract terms tied to data classification levels
Role for Data Classification Protection Levels matched to Protection Profiles Both vendor and university communicate in same framework Changes to policy, operations, applications, infrastructure described in terms of compatibility with protection level requirements (+/-)
Current Recommendations (Berkeley) Protection Level Data Category Permitted on Box? Permitted on Google? PL0 De-identified data Public consumption data Yes PL1 Student Education Records (FERPA) PL2 Patient Health Information (PHI) No Payment Card Industry (PCI) Information California State Law Notice‐Triggering Information Human Subject Research Data Export Controlled Data
Service Classification Example Protection Level Suitable Services Protection Profiles (Requirements & Standards) Risks or Variances PL0 Any MSS-networked devices PL1 Box Google Baseline data profile FIPPS controls for PII Auditing immature Adm access w/o notice Data leakage 3rd party apps PL2 Calshare EMR MSS-NTD HIPAA profile DB not encrypted None
Berkeley Data Classification Protection Level Impact Category Protection Profiles (Requirements & Standards) Examples PL0 Limited Availability Reliability Fair Use Published Open access PL1 Moderate Privacy impact assessment FIPPS controls for PII Baseline assessment Nondisclosure Student data Low value data PL2 High Full risk assessment Comprehensive security Need to know monitoring Actively regulated Home & family High value PL3 Mission Critical SSO DB
Conclusions Demystifying the Cloud Relationship Contracting Not just outsourcing arrangement Contract is essential to mediate the Cloud relationship Contract should retain institutional integrity, provide an opportunity for strategic planning, and create efficient/effective outcomes for the university Relationship Contracting Building a meaningful vendor relationship Defining the relationship terms Memorializing shared risk and responsibilities