Minimum Standards
Why Minimum Standards Matter
Minimum Standards establish a common cyber security baseline for protecting University systems, services, and data. They translate responsibilities into required auditable actions.
Responsibilities explain who is accountable, Minimum Standards define what must be done, and Guides and Playbooks explain how to do it in practice.
Getting Started
- Determine your role.
- Determine the Risk Classification for the data and/or services you use or manage.
- Review the standards relevant for your role.
- Custodians need to review the additional standards for systems, services and technology assets.
Community Members Minimum Standards
These standards apply to Community Members who use University data, systems, or other digital resources. For a complete role description, see Community Member Responsibilities.
Detailed implementation guides are linked within the sections below.
These standards apply to all University accounts and authentication credentials you use for University activities. Protecting your accounts is the first line of defense against unauthorized access to University systems and data.
| Standard | Applies To | Steps to Follow |
|---|---|---|
Multi-factor Authentication (MFA) | University accounts | Use passwordless authentication (preferred) or MFA where available. |
Strong, unique passwords | University accounts that require a password | Use a strong, unique password for each University account that requires a password. 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 authentication requests you did not initiate. Promptly report suspicious MFA prompts. |
Account recovery | Accounts with recovery options | Keep approved recovery information current. Protect recovery codes as you would passwords. |
Suspected compromise | University accounts | Immediately change affected credentials and report the suspected compromise using the University's incident-reporting process. |
These standards apply to computers, laptops, tablets, and mobile devices that you own and use for University activities. They also cover what to do when disposing of or returning a device that holds University Data.
| Standard | Applies To | Steps to Follow |
|---|---|---|
Network 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. |
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. |
Role Change | Personal devices used for University activities | Remove University Data, accounts, applications, and stored credentials before transferring to a new role or leaving 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 instead. |
These standards apply to University Data in any format. Electronic, printed, audio, visual, or other. They cover how you access, share, transmit, store, and dispose of information in your day-to-day University activities.
| Standard | Applies To | Steps to Follow |
|---|---|---|
Minimum 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 | 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. |
Report suspected or confirmed security and privacy incidents immediately. Do not wait for confirmation before reporting. Early reporting reduces risk to you, your colleagues, and the University.
| Standard | Applies To | Steps to Follow |
|---|---|---|
Report promptly | All incidents | Report suspected or confirmed security and privacy incidents immediately using the University's incident-reporting channels. |
Examples of incidents | All incidents | Treat the following as suspected incidents and report promptly: lost or stolen devices or records; phishing messages; unexpected MFA prompts; unauthorized access; accidental disclosure; or malware. |
Preserve information | All incidents | Preserve relevant messages, logs, records, or device information. Cooperate with response activities. |
System or Service Custodians (Custodians) Minimum Standards
Custodians must meet the Community Member Minimum Standards when using University resources, as well as the standards below when supporting IT resources used for University business. The Custodian remains accountable for ensuring these standards are met, including when implementation is performed by another Harvard team, vendor, or service provider. For a complete role description, see System or Service Custodian Responsibilities.
Implementation help:
For guidance on how to meet the Custodian Minimum Standards:
- Review the Custodian Configuration Guide
- Review the Custodian Implementation Playbooks. Link to Playbooks - coming soon!
All Systems and Services
These standards apply to all systems and services you manage or support, regardless of technology or hosting model.
These standards apply to every system or service you manage or support. They cover how to establish ownership, classify risk, maintain an inventory, configure systems securely, and manage data appropriately throughout the system lifecycle.
| 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 of these standards that is relevant. A single service may fall into more than one type (e.g., application + cloud) |
Asset inventory | Levels 2–5, all systems and services | Record the following in an approved inventory or attack-surface management process: owner, purpose, location, system type, Risk Classification, data class, criticality, environment, support team, and product. Update inventory periodically and as systems and services change. |
Secure configuration | All systems and services | Apply a baseline configuration and disable all 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 | Levels 2–5, all systems and services | Use current, supported encrypted protocols for University Data and Administrative Sessions. |
Encryption at rest | Levels 3–5, all systems and services | Use current, supported encryption controls to protect University Data at rest. |
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. |
These standards govern how accounts are created, secured, and managed for systems and services under your control. They cover authentication methods, account types, access reviews, session timeouts, and secrets management for user, administrator, service, vendor, and machine accounts.
Accounts & Authentication
| Standard | Applies when | Steps to Follow |
|---|---|---|
Harvard-managed authentication | All systems where technically feasible | Use HarvardKey or another approved Harvard-managed authentication service instead of local authentication wherever the platform supports it. |
Named accounts | Systems with user, administrator, service, vendor, or machine access | Use individually attributable accounts for users and administrators. Avoid shared accounts for routine activity. |
Local passwords | Systems that cannot use Harvard-managed authentication | Apply the Local Password standards (see Local Passwords section below), including minimum length, prohibited patterns, failed-attempt protection, reset rules, and secure storage. |
Remote authentication | All systems with remote authentication | Require MFA for all remote administrative and end user access where the platform supports it. |
Administrator accounts | Systems and services with administrative functions | Use dedicated administrator accounts for administrative tasks. Require MFA. Limit privileges to those necessary for the role. |
Role-based access | Systems and services that support role-based access | Use role-based access controls. Enforce server-side authorization for protected functions and information. |
Access lifecycle & secrets
| Standard | Applies when | Steps to Follow |
|---|---|---|
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. Disable privileged or high-risk accounts after 45 days of inactivity. 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 available. If not available, document and implement controls that: encrypt secrets; prevent hardcoding in source code; restrict access to secrets; audit access and use. |
General user sessions | General applications and SaaS | End inactive sessions after 2 hours. Require reauthentication after a maximum of 12 hours. |
Privileged or high-risk sessions | Privileged access and high-risk applications or SaaS | End inactive sessions after 15 minutes. Require reauthentication after a maximum of 8 hours. |
These standards apply only when a system cannot use HarvardKey or another Harvard-managed authentication service. Use Harvard-managed authentication wherever the platform supports it. Apply local password standards only as a fallback.
| Standard | Applies when | Action Required |
|---|---|---|
Password Length | All local password fields | Enforce a minimum length of at least 15 characters. Systems should support long passphrases up to at least 64 characters in length. |
Character Rules & Usability | All local password fields | Do not require specific character types (no mandatory uppercase, numbers, or symbols). Allow all printable ASCII characters, Unicode, and spaces. Password manager copy-and-paste functionality must be permitted. |
Automated Screening | All local password fields | Automatically screen all new or updated passwords against known breached password lists, common dictionary words, repetitive patterns, and user/organization contextual terms. |
Expiration | All local passwords | Do not enforce periodic password expiration. Forced resets (e.g., every 90 days or annually) are prohibited. Require resets only when compromise is suspected. |
Failed attempts | Systems using local passwords | Lock the account after 10 failed sign-in attempts or apply an approved equivalent rate-limiting control against password guessing. |
Storage | Systems storing local passwords | Store passwords only using an approved salted, adaptive password-hashing method (Argon2id or bcrypt). Never store readable passwords. |
Use vulnerability management to identify and remediate weaknesses in systems and services under your control. These standards cover the tools that must be in place, the timeframes for addressing findings, and the process for managing exceptions. They apply to endpoints, servers, applications, network infrastructure, and cloud components.
Vulnerability management capabilities
| Standard | Applies when | Steps to Follow |
|---|---|---|
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. 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 Exposures in UWVM scope with risk score 7.0 or higher | Use the approved cloud security-posture capability to address the risk, seek an approved exception, or designate as engineered “by-design”. |
Vulnerability treatment timelines & exceptions
| Standard | Applies when | Steps to Follow |
|---|---|---|
Critical vulnerabilities | UWVM risk score 9.5 or higher | Remediate, 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, obtain an approved exception, or obtain an approved false-positive designation within 30 days. |
Medium and Low vulnerabilities | UWVM risk score below 7.0 | Address through regular maintenance and at least monthly OS patching. |
Emergency vulnerabilities | Exploited vulnerabilities and immediate risks identified by UWVM | Escalate immediately and coordinate urgent response with the UWVM team. |
Exclusions (vulnerability exceptions, false positives, and true "positive by design”) | Findings not remediated within the required period | Use the formal exclusion process. Expired approvals require immediate action. |
Use logging to support security monitoring, troubleshooting, and incident response. These standards cover what logs to collect, how long to keep them, what data must not appear in logs, and what to do when a security incident occurs.
Logging
| Standard | Applies when | Steps to Follow |
|---|---|---|
Security logs | All systems and services | Collect relevant application, audit, authentication, administrative, security, and system logs. Keep at least 90 days searchable. |
Storage | Levels 3-5, Servers | Record and forward application, system, and security events to a centralized log management system. Do not store locally. |
Level 4–5 access logging | Levels 4–5, all systems and services | Log access to Level 4 and Level 5 University Data. |
Incident Response
| Standard | Applies when | Steps to Follow |
|---|---|---|
Incident response events | All levels, all systems and services | Report incidents promptly. Preserve relevant evidence and logs. Support response activities. Remediate significant findings from incidents or penetration tests. |
Apply these standards to any system or service operated, maintained, hosted, or supported by a third party, in addition to the relevant technology section for that system type. They cover procurement terms, risk assessments, vendor access, and offboarding.
| Standard | Applies when | Action Required |
|---|---|---|
Procurement and contract terms | Level 2-5 | Consult the appropriate University procurement team. Include required security, privacy, confidentiality, incident-notification, data-use, return, and retention terms. |
Risk assessment | 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 and MFA where supported. Limit access to the minimum necessary. 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 of University Data. Retain evidence of destruction when required. |
Technology Assets
In addition to the All Systems and Services standards above, these standards must be applied to specific types of technology assets.
These standards apply to University purchased or managed laptops, desktops and mobile devices. They cover device enrolment, encryption, firewalling, and secure disposal.
| Standard | Applies when | Action required |
|---|---|---|
Device management | All risk levels | Enroll devices in a endpoint device management platform and enforce a required baseline configuration. |
Encryption | All risk levels | Enable full-device encryption. |
Firewall | All risk levels | Enable and manage the host firewall. |
Secure destruction | All risk levels | Sanitize or destroy data and storage before reassignment, re-purposing, return, or disposal. |
Data Storage | Levels 4-5 | Do not store on a University device. Use an approved University system instead. |
These standards apply to printing and scanning devices that process University Data, including managed printers, multi-function devices, and any unmanaged devices on University networks. They cover access controls, secure transmission, job storage, and disposal of devices containing internal storage.
| Requirement | Applies To | Action required |
|---|---|---|
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 or "Personal" printers | Devices not integrated with central identity and firmware management, or operating on a guest or unsegmented network | Configure to protect Confidential Information. Do not print Level 3-5 information on unmanaged printers. |
These standards apply to all servers under your management, regardless of whether they are physical, virtual, on-premises, or cloud-hosted. They cover backup and recovery, firewall, network controls, log collection, and session management for administrative access.
| Standard | Applies when | Action required |
|---|---|---|
Secure destruction | Levels 2–5 | Sanitize or destroy storage before re-purposing or decommissioning. |
Backup | Levels 3–5 or when continuity requires it | Back up required systems, configurations, and data. |
Recovery validation | Levels 4-5 | Periodically test recovery. Confirm restoration within required time frames. |
Firewall | All risk levels | Implement and manage a host or network firewall. |
Outbound traffic | Levels 4-5 | Restrict outbound traffic to approved destinations and required services. |
Private addressing | Levels 4-5 | Use private IP addressing unless an approved design requires public exposure. |
Physical access | Levels 3–5 | Restrict physical access to server rooms, racks, consoles, and related infrastructure. |
Administrative sessions | SSH, RDP, console, and equivalent access | End inactive sessions after 15 minutes and require re-authentication after 8 hours maximum. |
These standards apply to custom applications, vendor applications requiring configuration, APIs, connectors, plugins, integrations, and research platforms. They cover authentication, input/output protection, Web Application Firewall use, denial-of-service controls, log collection, and API lifecycle management.
| Standard | Applies when | Action required |
|---|---|---|
Authentication and authorization | Non-public applications and APIs | Authenticate users or services. Enforce server-side authorization for every protected function and resource. |
Input and output protection | Applications and APIs | Validate requests and input. Protect output. Do not expose sensitive information in errors. |
Web Application Firewall | Web applications at Levels 3-5 | Use a Web Application Firewall or approved equivalent protection where available. |
Denial-of-service protection | Applications at Levels 4-5 | Apply appropriate denial-of-service and abuse protections. |
API credentials | APIs using keys or tokens | Use scoped, expiring credentials. 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. |
API inventory | Production APIs | Maintain a complete inventory of all production API endpoints and conduct periodic reviews. |
These standards apply to Software-as-a-Service and other provider-hosted applications used for University purposes. They cover administrative controls, sharing restrictions, audit logging, procurement requirements, and data destruction at contract end.
| Standard | Applies when | Action required |
|---|---|---|
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. |
These standards apply to infrastructure and platform services including AWS, Azure, Google Cloud, and other IaaS/PaaS providers. They cover administrative access, audit logging, public exposure controls, private addressing, procurement requirements, and risk assessments for sensitive environments.
| Standard | Applies To | Action required |
|---|---|---|
Administrative controls | All IaaS/PaaS | Use named administrators, MFA, least privilege, roles or managed identities, and approved secrets management. |
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 | Levels 4-5 | Use private IP addressing for applicable resources unless an approved design requires public exposure. |
These standards apply to network infrastructure including switches, routers, firewalls, wireless access points, VPN gateways, network-management systems, and related components. They cover administrative access, firewall rules, network segmentation, and wireless security protocols.
| Standard | Applies To | Action required |
|---|---|---|
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. |
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. |
Configuration Backup | Network infrastructure | Securely back up critical configurations and test restoration. |
Beyond the Basics: Privacy & Regulated Data
Protecting sensitive data takes more than following the Minimum Standards for IT security. Information such as student records, health details, and financial files demands custom steps to comply with legal and contractual rules. If you work with these data types, check the resources below to learn more.
Equivalents and Exceptions
Schools may use varying technologies and techniques to meet the expected outcomes of the Minimum Standards.
Equivalents
An equivalent technology or implementation technique may be used when it meets or exceeds the required security outcome. Using an equivalent is not an exception and does not require a formal exception request.
Exceptions
If the required outcome cannot be met:
- A formal exception must be requested and approved by the Chief Information Security and Data Privacy Officer (CISO/DPO) or designee.
- Vulnerability exceptions and false positives must also follow the applicable University-wide Vulnerability Management (UWVM) process.
- Expired exception approvals require immediate action.
Submit a formal exception for consideration.
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 Standards
Security and privacy requirements for protecting University information.
Roles & Responsibilities
Role-based guidance for supporting a secure University environment.