Body
The External Technology Systems and Data Hosting standard describes the requirements for appropriate and approved use of externally hosted Oakland University Systems and/or Data. This article outlines security, compliance, operational, and lifecycle requirements for external hosting solutions (IaaS, PaaS, SaaS).
Overview
The External Technology Systems and Data Hosting standard describes the requirements for appropriate and approved use of externally hosted Oakland University Systems and/or Data.
Scope
The External Technology Systems and Data Hosting standard applies to all data owned by OU or stored on, or utilized by Information Resources.
Standard
The purpose of this standard is to define security and compliance requirements for the adoption and use of external hosting solutions (e.g., cloud computing services), including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), to protect institutional data, ensure regulatory compliance, and manage risk.
All External Technology and Data Hosting services that store, transmit, or process University Data must be submitted for review by Oakland University Faculty or Staff through the Technology Investment process (login required). This review includes an evaluation of technical, security, and compliance controls, as well as related documentation, both before implementation and at intervals based on risk level.
To ensure robust information security and compliance when integrating external resources, the requesting unit, in collaboration with the designated Data Owner, is responsible for classifying data in accordance with the institution's Data Classification Standard prior to use with external resources.
Cloud security is a shared responsibility between the cloud service provider and the university. The division of responsibilities depends on the service model (e.g., IaaS, PaaS, SaaS).
Role and Responsibilities must be clearly understood and documented prior to utilizing external services.
Every cloud service contract requires clear contractual language to guarantee that vendor services satisfy University operational, security, and compliance requirements. Strong language sets clear expectations for performance, ongoing support, and data protection throughout the contract lifecycle.
While specific needs vary by project, UTS partnered with Purchasing and Office of Legal Affairs to include OU requirements directly into Oakland University's Terms and Conditions (T&Cs) and as an addendum for contracts. While these documents should cover most needs, unique circumstances may require modifying a vendor's language or create language from scratch. In those cases the language in Appendix can be used as a reference.
Requirements
General - All Models
- Accessibility: All providers must adhere to the Americans with Disabilities Act (ADA) and demonstrate compliance with Web Content Accessibility Guidelines (WCAG) 2.1 AA or higher.
- Risk Assessment: Risk will be enumerated and communicated utilizing the IT Security Scorecard completed by the Information Security Office.
- Security & Privacy Controls: Cloud providers must implement appropriate administrative, technical, and physical safeguards aligned with recognized standards (e.g., ISO 27001, SOC 2 Type II, FedRAMP, NIST 800-53).
- Data Sovereignty: University data must remain in geographic regions legally permissible under applicable regulations (e.g., FERPA, HIPAA, GDPR).
- Incident Response: Vendors must notify the institution within 24 hours of learning about any data breach or security incident that affects institutional data.
- Audit Rights: The university reserves the right to assess the cloud provider's security posture, including access to independent audit reports/certifications.
- Encryption: Confidential and Internal data must be stored and transmitted using encryption protocols that align with OU Standards, NIST-approved cryptography standards, and applicable regulatory, compliance, contractual requirements.
SaaS-Specific
Software as a Service (SaaS) is a cloud-based distribution model where applications are hosted by a third-party provider and delivered to OU.
- Access Controls: Integrate with a UTS approved, centrally managed authentication method, and support multi-factor authentication (MFA).
- Logging & Monitoring: The application must provide logging capabilities for user activity and administrative actions, and have the capability to integrate with UTS's central log management solutions. Logs should be retained in accordance with the UTS Logging and Management Standard.
- Data Portability: Vendor must provide a method to export data in a usable format upon contract termination.
- Configuration Management: SaaS platforms should support role-based access and restrict administrative privileges to authorized users only.
SaaS Shared Responsibility Model:
- Cloud Provider: Unless otherwise stated in contract Entire stack, including base application and infrastructure.
- University: User access management, data classification, integrations, and compliance with the University's policies and standards.
IaaS-Specific
- Network Security:
- All resources must be placed in a Virtual Private Cloud (VPC) or equivalent.
- Use of firewalls, network ACLs, and security groups to restrict access.
- Remote access must be secured using VPN or bastion hosts with MFA.
- OS & Patch Management:
- All virtual machines must be hardened according to an applicable, UTS approved, standard such as those provided by the Center for Internet Security (CIS) Benchmark.
- Systems must be patched monthly or per Oakland's vulnerability management policy.
- IAM Policies:
- The principle of least privilege must be enforced.
- Use cloud-native IAM roles and policies to restrict access.
- Logging & Monitoring: Cloud-native tools (e.g., AWS CloudTrail, Azure Monitor, etc.) must be enabled for auditing and security alerts; information should be retained in accordance with the UTS Logging and Management Standard.
- Backup & Disaster Recovery:
- Irreplaceable data, identified by business owners, must be backed up at a frequency sufficient to support business recovery objectives.
- DR procedures must be tested to a level sufficient for business recovery objectives and tested at least annually.
IaaS Shared Responsibility Model:
- Cloud Provider: Physical infrastructure, virtualization, core networking.
- University: Operating System (OS), applications, access control, data, and network configuration.
PaaS-Specific
- Secure Development Lifecycle (SDLC): All development in PaaS environments must follow secure coding standards and undergo security testing (e.g., SAST/DAST).
- Dependency Management: Libraries and packages must be routinely scanned for vulnerabilities.
- Secrets Management: API keys, passwords, and tokens must not be hardcoded or stored in source code repositories; use secure secrets management tools.
- Data Segmentation: Environments should be segmented by purpose (e.g., dev/test/prod) and restrict access between them.
PaaS Shared Responsibility Model:
- Cloud Provider: IaaS and Operating System (OS) and platform runtime.
- University: Application logic, data, and access control.
Roles and Responsibilities
Chief Information Officer
The Chief Information Officer is responsible for approving this standard.
Chief Information Security Officer
Serves as the primary contact for interpretation, monitoring, and enforcement of this standard.
- Partner with key University stakeholders to identify, document, and mitigate security, compliance, and contractual risks associated with security (e.g. data destruction, data sovereignty, etc.).
Director IT Business Operations
- Partner with key University stakeholders to identify, document, and mitigate contractual risks associated with operations (e.g. licensing, uptime, etc.).
Business Owner & Application Administrator
- Per the Application Administrator Standard, applicable parties including Business Owner, Application Owner (e.g. purchasing department), must comply with the requirements of this standard and any related policies, standards or security guidelines and procedures that may be issued by their departmental IT units and/or owners of the IT Resource(s) and Data they access. The individual / department procuring the solution is responsible for ensuring metrics, such as up-time, are sufficient to meet their needs.
Waivers and Exceptions
Compliance with this standard is mandatory.
Contact the Information Security Office with any questions or to request an exception from this standard.
Definitions
Capitalized terms used herein without definition are defined in the IT Terminology Standard.
Appendix
The following terms outline standard topics and performance metrics to address within a Service Level Agreement (SLA), contract, or Terms & Conditions (T&Cs). This framework serves as a baseline and can be customized to suit the requirements of individual agreements.
Operational
Definition of Services
Language must provide a clear and detailed description of the services being delivered, including service components, dependencies, and boundaries of responsibility.
- Clearly identify all components of the service being delivered (e.g., storage, compute, application features, integrations).
- Define responsibilities of both the provider and the university under the Shared Responsibility Model.
- Specify service boundaries, including what is and is not included in the scope of service.
- Outline any dependencies on third-party services or subcontractors.
- Identify any limitations on capacity, performance thresholds, or concurrent user access.
Service Availability
Providers must commit to defined uptime metrics, describe acceptable maintenance windows, and specify penalties or remedies for not meeting availability targets.
- Minimum uptime of 99.9% for production systems.
- Definition of scheduled maintenance windows and notification timelines.
- Remedies or penalties for failure to meet uptime commitments.
Incident Response and Resolution
Language must outline required timelines for incident acknowledgment, escalation, and resolution, including criteria for incident severity.
- Response Time: Initial acknowledgment of critical security incidents within 1 hour.
- Resolution Time: Defined target resolution timelines based on incident severity levels.
- Clear escalation procedures and communication protocols.
- Communication channels, and roles and responsibilities should be clearly articulated (e.g., Who is authorized to communicate on each party's behalf, and what methods such as support portal, email, phone, etc. are supported?).
Support Services
Support expectations must be documented, including available communication channels, response times, and hours of operation (e.g., 24/7 or business hours).
- Support hours (e.g., 24/7, business hours) and available channels (e.g., email, phone, portal).
- Designated account representative or technical contact for escalations.
- Communication channels and roles and responsibilities should be clearly articulated (e.g., Who is authorized to communicate on each party's behalf, and what methods are supported?).
Data Management Commitments
Language must describe data backup frequency, retention, and disaster recovery parameters, including Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
- Data Backup Frequency: Regular backups (e.g., daily) and retention periods.
- Disaster Recovery Objectives:
- Recovery Time Objective (RTO): e.g., < 4 hours.
- Recovery Point Objective (RPO): e.g., < 1 hour.
- Data portability and timelines for returning or deleting data upon contract termination.
Change Management
Providers must notify the university of any significant changes to service infrastructure, APIs, or security practices and define change control procedures.
- Advance notice of planned changes, upgrades, or deprecations affecting service availability or functionality.
- Notification of changes to underlying infrastructure, APIs, or security policies.
- Communication channels for change communications (e.g., website posting, support portal, email) should be documented.
Performance Monitoring
Language must ensure availability of dashboards, reporting tools, or logs for real-time service health and operational transparency.
- Availability of dashboards or reporting tools to monitor service health and adherence to metrics.
- Log retention and access are aligned with University standards.
Security & Compliance
Compliance and Reporting
Language should include provisions for providing audit reports (e.g., SOC 2, ISO 27001), periodic performance metrics, and breach notifications.
- Agreement to provide audit reports (e.g., SOC 2 Type II, ISO 27001) annually.
- Agreement to provide compliance reports (e.g., Voluntary Product Accessibility Template (VPAT) and Payment Card Industry Self Assessment Questionnaire (PCI SAQ)).
- Performance metrics and incident reports are shared quarterly or upon request.
- The method of information exchange (e.g., whether reports will be proactively distributed or provided on request) should be clearly articulated.
Protection of University Data
Language must affirm that university data will be protected in accordance with institutional policies and applicable regulations, including encryption, secure storage, and access controls.
- University data must be encrypted in transit and at rest using methods that align with NIST standards and current industry best practices (e.g., AES-256, TLS 1.2+).
- Access to university data must be restricted to authorized personnel based on role and the principle of least privilege.
- Provider must not use university data for advertising, analytics, training models, or any other purpose not explicitly authorized by contract.
- The provider must implement and maintain administrative, technical, and physical safeguards that are consistent with all applicable regulations (e.g., FERPA, HIPAA, GDPR, PCI, etc.).
- The provider must notify the university of any unauthorized access, breach, or compromise of university data within 24 hours.
Termination of Agreement
Language must include terms ensuring that, upon termination, the university's data is securely returned or destroyed within a defined timeframe and that no data is retained by the provider beyond this period.
- Provider must return all university data in a mutually agreed-upon, readable format within 30 days of contract termination.
- All copies of university data must be securely deleted from the provider's systems, backups, and third-party storage within 60 days unless otherwise required by law.
- Provider must certify, in writing, that data deletion has been completed in accordance with contract terms.
- Transition assistance (e.g., data export, documentation, limited support) must be provided to ensure continuity and minimize disruption.
- Language must specify data handling during temporary service suspensions or disputes, to avoid loss or inaccessibility.
Intellectual Property and Copyright
Members of the University community are responsible for respecting intellectual property rights when using, sharing, or storing content in cloud services.
- University-owned marks, logos, images, and symbols are the property of the institution and may not be used or reproduced without permission from University Communications and Marketing (UCM).
- Users must follow the Acceptable Use Policy and understand the appropriate use of copyrighted materials, trademarks, and patents in accordance with university and legal requirements.
Privacy and Data Security
All users of cloud services must handle institutional data in accordance with University policies and standards, federal and state laws, and contractual obligations. Special care must be taken to ensure that regulated or sensitive information is used, stored, and shared appropriately.
- Data must be managed according to the university's Data Classification Policy, which categorizes information as Confidential, Internal, or Public. Each category has specific handling requirements.
- Personally Identifiable Information (PII) must be protected in compliance with applicable laws and standards, including HIPAA, HITECH, FERPA, PCI-DSS, and state privacy regulations.
- Student education records must be handled in accordance with FERPA guidelines.
- Protected Health Information (PHI) must be used only in systems and workflows that comply with HIPAA requirements.
- Export-controlled information must be managed in compliance with U.S. export control regulations.
Data Availability and Records Retention
To ensure compliance and operational continuity, university data must remain accessible and retained in accordance with institutional and regulatory requirements.
- All academic, administrative, and research data must be retained according to University Policy 481 Records Retention and Disposal.
- Business Owners / Application Administrators are responsible for ensuring that their data is regularly backed up and stored in a recoverable format. Many cloud service providers do not guarantee recovery of deleted or corrupted data unless explicitly included in the service contract.
Last Modified: 10/27/2026
Authority: Approved by University Technology Services (UTS) Chief Information Officer
Category: Security Standards
Status: Published
Additional Support
OU Technology Center
44 Oakland Center
Rochester, MI 48309-4479
(248) 370-4357
Office Hours: M-F 8:00am - 5:00pm