# Minimum Standards ![hand using a pencil noting on notepad](/sites/g/files/omnuum12036/files/styles/hwp_1_1__360x360_scale/public/2026-06/standardschecklist2.jpeg?itok=RrStdl5u) ## Why Minimum Standards Matter Minimum Standards establish a common cyber security baseline for protecting University systems, services, and data. They translate responsibilities into required actions. If you are a **System or Service Custodian**, use these standards to **secure the systems or services** you control, manage, or support and to meet the requirements of the University Information Security Policy. If you are a **Community Member,** use these standards to **secure your** **personal devices, accounts and passwords**. ## Steps to Follow The University Minimum Standards identify the actions required to protect University data, systems, and services. 1. Determine the applicable [Risk Classification](/classify-risk "Classify Risk"). 2. Review the standards for your role. 3. If you manage a system or service, review All Systems and Services and each technology tab that apply. **This is the place to add a blurb and a link to** [**BUT WAIT THERE'S MORE!!!**](/additional-guidance "Additional Guidance") **e.g. Privacy, regulatory, special cases, etc.** ## Community Member Minimum Standards These standards apply to Community Members who use University data, systems, or other digital resources. For the full role description, review [Community Member Responsibilities](/community-members-responsibilities "Community Members Responsibilities"). Accounts and Passwords Personal Devices University Data Incident Reporting ## Accounts and Passwords University accounts and authentication credentials used for University activities. SortStandardApplies ToSteps to FollowPasswordless authentication and MFA University accounts Use passwordless authentication or multi-factor authentication where available. Strong, unique passwords University accounts that require a password Use a strong, unique password for each University account that requires one. Use HarvardKey or another Harvard-managed authentication service where available. Credential protection Named University accounts Never share passwords, MFA codes, recovery codes, access tokens, or other credentials. Unexpected authentication requests Accounts using MFA Deny and promptly report requests you did not initiate. Account recovery Accounts with recovery options Keep approved recovery information current and protect recovery codes. Suspected compromise University accounts Immediately change affected credentials and report the suspected compromise. Implementation help: Review the [Accounts, Passwords, and MFA Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/02_Accounts_Passwords_and_MFA_Implementation_Guide.docx?d=w80eed403f1c249718bfc37e628030868&csf=1&web=1&e=JK4gkb). HarvardKey required. ## Personal Devices Computers, laptops, tablets, and mobile devices purchased and maintained by a Community Member. SortStandardApplies ToSteps to FollowNetwork access Personal devices connecting to Harvard networks Use the appropriate Harvard network and register the device when required. Updates Personal devices used for University activities Enable automatic operating system and application updates. Do not use devices that no longer receive security updates. Device authentication Personal devices used for University activities Protect the device with a strong password, PIN, or biometric. Screen lock Personal devices used for University activities Configure the device to lock automatically after 15 minutes or less of inactivity. Encryption Personal devices used for University activities Enable full-device encryption.. Required protections Personal devices used for University activities Do not disable or bypass controls required by the University. Level 4 and Level 5 Data All personal devices Do not store Level 4 or Level 5 University Data on a personal device. Use an approved University system. Application Permissions Personal devices used for University activities Allow applications to access only the information and device features required for an approved use. Disposal Personal devices used for University activities Remove University Data, accounts, applications, and stored credentials before sale, transfer, recycling, or disposal. Securely erase the device using an approved method. University-Owned Devices Devices purchased by the University Remove University data, accounts, applications, and credentials before selling, transferring, recycling, or disposing of a personal device. Return University-owned devices to the responsible IT organization. Implementation help: Review the [Personal Device Security Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/03_Personal_Device_Security_Implementation_Guide.docx?d=wb09e740685f84b599b42201f58b00397&csf=1&web=1&e=oStMH9) and [Secure Device and Media Disposal Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/04_Secure_Device_and_Media_Disposal_Implementation_Guide.docx?d=w9f8892daf4824080b6b3e91a6e465d41&csf=1&web=1&e=eBQ6JC). HarvardKey required. ## University Data University Data in electronic, printed, audio, visual, or other formats. SortStandardApplies ToSteps to FollowMinimum necessary All University Data Access, collect, use, and retain only the information necessary for an approved University purpose. Approved systems All University Data Store and process University data only in systems and services approved for its Risk Classification. Secure sharing Levels 2–5 Share only with authorized people who need the information for a University purpose. Public access Levels 2–5 Do not make Confidential Information publicly accessible or use unrestricted sharing links. Secure transmission Levels 3–5 Use approved encrypted University systems to transmit or share information. Removable media University Data stored on removable media Use removable media only when permitted and use approved encryption and access protection appropriate to the Risk Classification. Printing and scanning Levels 3–5 Use an approved printing or scanning service. Retrieve output promptly, verify scan destinations, remove originals, and report misdirected or exposed jobs. Physical records Printed or other physical records Secure records when unattended and use locked storage where appropriate. Retention and disposal All University Data Retain information only as long as required by the General Records Schedule, law, contract, research requirements, or business need. Secure Disposal All University Data Follow the General Records Schedule and securely delete or destroy information when it is no longer required. Implementation help: Review additional [Data Handling Guidance](/shield-data "Shield Data"). ## Incident Reporting Promptly report suspected or confirmed security and privacy incidents. SortStandardApplies ToSteps to FollowReport promptly All incidents Report suspected or confirmed security and privacy incidents immediately. Examples All incidents Lost or stolen devices or records; phishing; unexpected MFA prompts; unauthorized access; accidental disclosure; malware; or unusual system behavior. Preserve information All incidents Preserve relevant messages, logs, records, or device information and cooperate with response activities. Implementation help: Review [Incident Reporting](/get-help "Get Help") or [Phishing Reporting](/prevent-phishing "Prevent Phishing") procedures. ## System or Service Custodian Minimum Standards Custodians must meet the Community Member Minimum Standards and the standards below. The Custodian remains accountable for ensuring the standards are met, including when implementation is performed by another Harvard team, vendor, or service provider. Review the [System or Service Custodian Responsibilities](/system-administrators-responsibilities "System or Service Custodian Responsibilities") page for additional details. ### All Systems and Services These standards apply to each University system or service managed by a Custodian. Open all sections Close all sections ### Ownership, Configuration, Data, Logging, and Incidents expand\_more Sort**Standard****Applies when****Steps to Follow**Assigned Custodian All systems and services Identify and document at least one System or Service Custodian. The Custodian remains accountable when implementation is performed by another team, vendor, or provider. Risk Classification All systems and services Determine and document the applicable University Risk Classification. Reassess after significant changes. Applicable system types All systems and services Apply every system or service section that is relevant. A single service may fall into more than one type. Asset inventory Levels 3-5; and all technology assets in UWVM scope Record owner, purpose, location, system type, Risk Classification, data class, criticality, environment, support team, and product in the approved inventory or attack-surface management process. Secure configuration All systems and services Apply an approved baseline and disable unnecessary services, protocols, ports, features, and software. Default accounts All systems and services Disable unnecessary default accounts and replace default credentials before production use. Supported technology All systems and services Use supported hardware, software, applications, libraries, firmware, and services. Retire or isolate unsupported assets. Encryption in transit All systems and services Use current, supported encrypted protocols for University Data and administrative access. Data retention All systems and services Retain University Data only as long as required by the General Records Schedule, law, contract, research requirements, or business need. Security logs All systems and services Collect relevant application, audit, authentication, administrative, security, and system logs. Keep at least 90 days searchable and one year archived, unless another requirement is longer. Level 4 and Level 5 access logging Levels 4-5 Log access to Level 4 and Level 5 University Data. Incident response All systems and services Report incidents promptly, preserve relevant evidence, support response activities, and remediate significant findings from incidents or penetration tests. ### Access and Identity expand\_more Sort**Standard****Applies when****Steps to Follow**Harvard-managed authentication All systems where technically feasible Use HarvardKey or another approved Harvard-managed authentication service. Named accounts Systems with user, administrator, service, vendor, or machine access Use individually attributable accounts. Avoid shared accounts for routine activity. Local passwords Systems not using Harvard-managed authentication Apply the local password requirements on this page, including length, prohibited patterns, failed-attempt protection, and reset rules. Remote authentication All systems with remote authentication Require MFA. Administrator accounts Systems and services with administrative functions Use dedicated administrator accounts, require MFA, and limit privileges to those necessary. Role-based access Systems and services that support roles Use role-based access and enforce authorization for protected functions and information. Role changes and departures Systems with managed authorization Change or remove access promptly when a person changes roles or leaves. Account inventory Systems with local or platform-managed accounts Maintain an inventory of user, administrator, service, emergency, vendor, and machine accounts. Dormant accounts Systems with local or platform-managed accounts Disable standard accounts after 90 days of inactivity and privileged or high-risk accounts after 45 days. Remove or archive dormant accounts after 180 days, unless an approved exception applies. Access reviews Systems with managed access Review standard access at least annually and privileged, high-risk, and Level 4-5 access at least quarterly. High-level administrative and service secrets Systems with high-level administrative or service accounts Change, reset, rotate, or otherwise update authentication secrets at least annually and after suspected compromise or relevant personnel changes. Secrets management Levels 4-5 systems and services that use passwords, API keys, certificates, or tokens Use an approved secrets-management capability where supported. Otherwise document controls that encrypt secrets, prevent hardcoding, restrict access, and audit use. General user sessions General applications and SaaS End inactive sessions after 2 hours and require reauthentication after 12 hours maximum. Privileged or high-risk sessions Privileged access and high-risk applications or SaaS End inactive sessions after 15 minutes and require reauthentication after 8 hours maximum. ### Local Passwords expand\_more These requirements apply when a system cannot use HarvardKey or another Harvard-managed authentication service. Sort**Standard****Steps to Follow**Preferred method Use HarvardKey or another approved Harvard-managed authentication service. Preferred local length Require at least 20 characters where the platform supports it. Shorter local passwords When a platform cannot support 20 characters, prohibit common names and dictionary words, prohibit sequences of more than four digits, and require characters from at least three of four categories: uppercase, lowercase, digits, and special characters. 10-20 characters Do not require routine expiration unless compromise, ownership change, or another requirement makes a reset necessary. 8-9 characters with MFA Do not require routine expiration. 8-9 characters without MFA Require at least annual expiration. Failed attempts Lock the account after 10 failed sign-in attempts or apply an approved equivalent protection against password guessing. Storage Store passwords only using an approved salted, adaptive password-hashing method. Never store readable passwords. ### Vulnerability Management expand\_more Sort**Standard****Applies when****Steps to Follow**Endpoint Detection and Response Supported University endpoints and servers, all risk levels Deploy and maintain the University-standard EDR capability or an approved equivalent. Security updates Endpoints, servers, applications, network infrastructure, firmware, and patchable cloud components Apply current security updates within University-required timeframes. Patch operating systems at least monthly. Server vulnerability scanning Servers, all risk levels Install the approved scanning agent where supported and run daily agent-based scans wherever possible. Network vulnerability scanning Network Infrastructure, Levels 4-5 Conduct regular vulnerability scans using an approved process. Cloud security posture Cloud Infrastructure in UWVM scope Use the approved cloud security-posture capability and route findings to the responsible team. Critical vulnerabilities UWVM risk score 9.5 or higher Remediate, mitigate, obtain an approved exception, or obtain an approved false-positive designation within 5 business days. High vulnerabilities UWVM risk score 7.0 or higher Remediate, mitigate, obtain an approved exception, or obtain an approved false-positive designation within 30 days. Medium and Low vulnerabilities Below High Address through regular maintenance and at least monthly OS patching unless UWVM or another requirement sets a shorter deadline. Emergency vulnerabilities Exploited vulnerabilities, score 9.5 or higher, or immediate risks identified with UWVM Escalate immediately and coordinate urgent response with the UWVM team. Vulnerability exceptions and false positives Findings not remediated within the required period Use the formal, time-limited exception or false-positive process. Expired approvals require immediate action. ### Vendor Managed or Contracted Service expand\_more Any system or service operated, maintained, hosted, or supported by a third party. Apply this section in addition to the relevant technology section. Sort**Standard****Applies when****Steps to Follow**Procurement and contract terms All vendor-managed or contracted services Consult the appropriate University procurement team and include required security, privacy, confidentiality, incident-notification, data-use, return, and destruction terms. Risk assessment At Risk Levels 4-5 Complete the required assessment before contract execution or service use. Vendor access Services with vendor or support access Use named accounts where possible, require appropriate authentication, limit access to the minimum necessary, and remove access when no longer required. Offboarding and data destruction All vendor-managed or contracted services at service end Remove access and integrations, return required records, confirm secure destruction, and retain evidence when required. Implementation help: Review the [System or Service Custodian Implementation Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ### Asset Types In addition, these requirements apply to specific technology asset types. Endpoints Printers Servers Applications SaaS IaaS Networks ## Endpoints Laptops, desktops, mobile devices, and other University managed endpoints. Sort**Standard****Applies when****Steps to Follow**Device management All risk levels Enroll supported devices in the approved management platform and enforce required configuration profiles. Encryption All risk levels Enable full-device encryption. Level 4-5 endpoint storage is not authorized by this requirement; follow Data Handling and any separately approved environment requirements. Firewall All risk levels Enable and manage the host firewall. Secure destruction All risk levels Sanitize or destroy data and storage before reassignment, repurposing, return, or disposal. Backup Levels 3-5 or when continuity requires it Back up required data and configurations consistent with documented continuity requirements. Implementation help: Review the Devices section of the [System or Service Custodian Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ## Printers Printing and scanning devices that process University Data. Sort**Requirement****Applies To****Steps to Follow**Permissions Managed printers and multi-function devices Restrict administrative and network access and require authentication for protected printing and scanning. Secure transmission and destinations Protected print and scan workflows Encrypt traffic. Restrict scanning to authenticated University mailboxes and approved secure storage. Block unauthenticated, external, and guest fallback destinations. Stored jobs and scans Devices that temporarily store jobs Delete completed and held jobs within 2 hours. Delete failed, abandoned, or expired jobs immediately where possible and no later than 24 hours. Secure release Print jobs containing Confidential Information Require release by an authorized user at the device or through another approved secure-release method. Secure disposal Devices containing internal storage Sanitize or destroy internal storage before return, transfer, reuse, or disposal. Unmanaged Printers Any device not integrated with central identity and firmware management, or operating on a guest or unsegmented network Configure to protect Confidential Information. No Level 4 printing. Implementation help: Review the [Configure and Manage Printers Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/07_Configure_and_Operate_Managed_Printers_Securely.docx?d=wddd7a6462d5b4beeaca6d8b90bd857d7&csf=1&web=1&e=xnhcqh). HarvardKey required. ## Servers Physical, virtual, on-premises, and cloud-hosted servers. Sort**Standard****Applies when****Steps to Follow**Encryption at rest Servers at Levels 3-5 Encrypt University Data at rest. Secure destruction Servers, all risk levels Sanitize or destroy storage before repurposing or decommissioning. Backup Servers at Levels 3-5 when continuity requires it Back up required systems, configurations, and data. Recovery validation Servers at Levels 4-5 Periodically test recovery and confirm restoration within required timeframes. Firewall Servers, all risk levels Implement and manage a host or network firewall. Outbound traffic Servers at Levels 4-5 Restrict outbound traffic to approved destinations and required services. Private addressing Servers at Levels 4-5 Use private IP addressing unless an approved design requires public exposure. Physical access Servers at Levels 3-5 Restrict physical access to server rooms, racks, consoles, and related infrastructure. Separate log collection Servers at Levels 3-5 Send relevant logs to a collection system separate from the source system. Administrative sessions SSH, RDP, console, and equivalent access End inactive sessions after 15 minutes and require reauthentication after 8 hours maximum. Implementation help: Review the Servers section of the [System or Service Custodian Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ## Applications Custom applications, vendor applications requiring configuration, APIs, connectors, plugins, integrations, and research platforms. Sort**Standard****Applies when****Steps to Follow**Authentication and authorization Non-public applications and APIs, all risk levels Authenticate users or services and enforce server-side authorization for every protected function and resource. Encryption at rest Applications at Levels 3-5 Encrypt University Data at rest. Input and output protection Applications and APIs, all risk levels Validate requests and input, protect output, and do not expose sensitive information in errors. Web Application Firewall Web applications at Levels 3-5, where available Use a Web Application Firewall or approved equivalent protection. Denial-of-service protection Applications at Levels 4-5 Apply appropriate denial-of-service and abuse protections. Separate log collection Applications at Levels 3-5 Send relevant logs to a collection system separate from the source system. API credentials APIs using keys or tokens Use scoped, expiring credentials and do not place secrets in source code, URLs, logs, or client-side applications. API abuse protection Externally accessible or high-volume APIs Apply rate limiting, quotas, throttling, or an approved equivalent. API lifecycle Production APIs Document ownership, consumers, versions, support dates, deprecation, and endpoint retirement. Implementation help: Review the Applications section of the [System or Service Custodian Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ## SaaS Software-as-a-Service and other provider-hosted applications. Sort**Standard****Applies when****Steps to Follow**Administrative controls All SaaS Use named administrators, Harvard-managed authentication where supported, MFA, and least privilege. External sharing SaaS that supports sharing Disable anonymous access and unrestricted public links unless specifically required and approved. Audit logging SaaS where logs are available Enable authentication, administrative, sharing, security, and configuration logs. Procurement and contract terms All SaaS acquisitions or renewals Consult the appropriate University procurement team and include required security, privacy, data-use, incident-notification, return, and destruction terms. Risk assessment SaaS at Levels 3-5 or otherwise enhanced risk Complete the required assessment before contract execution or service use. Data destruction All SaaS at contract or service end Confirm return or secure destruction of University Data and retain evidence when required. Denial-of-service protection SaaS at Levels 4-5 Confirm the provider supplies appropriate denial-of-service protection. Implementation help: Review the SaaS and Cloud sections of the [Custodian Implementation Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ## IaaS AWS, Azure, Google Cloud, and other infrastructure or platform services. Sort**Standard****Applies To****Steps to Follow**Administrative controls All IaaS/PaaS Use named administrators, MFA, least privilege, roles or managed identities, and approved secrets management where required. Cloud audit logging All IaaS/PaaS Enable provider audit and administrative logging across all accounts, subscriptions, projects, or equivalent environments. Public administrative access All IaaS/PaaS Do not expose SSH, RDP, management consoles, or equivalent administrative services directly to the Internet unless specifically approved. Private addressing IaaS/PaaS at Levels 4-5 Use private IP addressing for applicable resources unless an approved design requires public exposure. Procurement and contract terms All contracted IaaS/PaaS Consult the appropriate University procurement team and include required terms. Risk assessment IaaS/PaaS at Levels 3-5 or otherwise enhanced risk Complete the required assessment before contract execution or service use. Data destruction All contracted IaaS/PaaS at service end Confirm return or secure destruction of University Data and retain evidence when required. Implementation help: Review the SaaS and Cloud sections of the [Custodian Implementation Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=ENG26g). HarvardKey required. ## Networks Switches, routers, firewalls, wireless access points, VPN gateways, network-management systems, and related infrastructure. Sort**Standard****Applies To****Steps to Follow**Administrative Access All network infrastructure Restrict management interfaces to authorized administrators and approved management networks. Firewall Rules Firewalls and network controls Allow only traffic required for an approved purpose; use least-access or default-deny principles where appropriate. Segmentation Sensitive or specialized environments Separate user, server, administrative, IoT, research, and other environments according to risk. Public Administrative Access All network infrastructure Do not expose management interfaces directly to the Internet unless specifically approved. Wireless Security University wireless infrastructure Use approved enterprise wireless-security protocols. Rogue Device Detection Environments where required Detect and respond to unauthorized network devices and wireless access points. Configuration Logging All network infrastructure Log administrative access and configuration changes. Remote Administration All network infrastructure Use approved encrypted protocols, MFA, and secure access paths. Session Limits VPN and network administration End after 15 minutes of inactivity and require reauthentication after 8 hours maximum. Configuration Backup Network infrastructure Securely back up critical configurations and test restoration. Implementation help: Review the Networks section of the [Custodian Implementation Guide](https://hu.sharepoint.com/:w:/r/sites/hrci-Information_Security/Shared%20Documents/Programs%20and%20Projects/Awareness/Webpage/06_System_or_Service_Custodian_Implementation_Guide.docx?d=w788b806f672b43e59aa578af183bd110&csf=1&web=1&e=38nh6b). HarvardKey required. --- **THE CONTENT BELOW IS IN PROCESS OF BEING REWORKED.** ## Why Privacy Matters in Applying Standards At Harvard, we are dedicated to safeguarding personal data. Securing technology assets is an important step but not all that is required. Certain information, including health and financial data, may require additional steps to comply with a law and/or regulation. For additional guidance and training, [visit the Privacy Principles page](https://privsec.harvard.edu/privacy-principles). Sometimes contracts, laws, university rules, or system limits mean we have to use extra or different protections than our usual standards. [View examples and guidance](https://privsec.harvard.edu/additional-guidance) to help you recognize and handle these situations correctly. *This section to be removed.* Researchers should also review [OVPR Research Data Management guidance](https://research.harvard.edu/research-policies-compliance/research-data-management/). Contractual, legal, institutional, or system requirements may require additional or different safeguards. Open all sections Close all sections ### Examples: When Contractual or Legal Requirements May Override These Standards expand\_more - **Regulated Data (HIPAA, FERPA, PCI DSS):** You may need to set up systems with special security controls like encryption or audit logs for health, student, or credit card data. - **Sponsored Research Projects:** Grant or sponsor requirements might require you to use specific security standards (like NIST or FISMA) when configuring your systems. - **Vendor or Cloud Agreements:** Some contracts with vendors or cloud providers may limit which security settings or locations you can use for your systems. - **International Data Laws (GDPR):** Sometimes, you must configure systems to store or process data only in certain regions to follow international or local laws. ### Examples: When Institutional Policy or System Limitations May Override These Standards expand\_more - **Legacy Systems:** There may be older (legacy) systems that cannot meet every aspect of the Minimum Standard (for example, lacking support for modern encryption). - **Vendor Constraints:** Some third-party software or platforms may have built-in restrictions that prevent full alignment with the Minimum Standard. - **Business Continuity/Emergency Needs:** During declared emergencies or business continuity events, temporary exceptions might be required for operational needs. - **Accessibility and Accommodation** To accommodate Community Members with disabilities, alternative configurations or technologies might be required. *In these cases, documented exceptions and compensating controls are typically required.* ## Related Resources Use these resources to take the next step, find University guidance, or explore trusted external references. ### University Policies Official University policies and governance guidance. - [University Information Security Policy](/information-security-policy-archived "Information Security Policy - Archived") - [OVPR Research Data Management and Policy Compliance Resources](https://research.harvard.edu/research-policies-compliance/research-data-management/) - [General Records Schedule](https://library.harvard.edu/services-tools/general-records-schedule) (GRS) ### University Standards Security and privacy requirements for protecting University information. - [Risk Classification](/classify-risk "Classify Risk") - [Data Handling](/data-handling "Data Handling") ### Roles & Responsibilities Role-based guidance for supporting a secure University environment. - [Community Members](/community-members-responsibilities "Community Members Responsibilities") - [System or Service Custodian](/system-administrators-responsibilities "System or Service Custodian Responsibilities") - [Data Stewards](/data-stewards-best-practices "Data Stewards Best Practices")