Minimum Web Standards
Minimum web standards (MinWeb) are the requirements and recommendations for the creation, hosting, management, and decommissioning of web properties at Stanford.
Site owners are ultimately responsible for complying with security, privacy, branding, and accessibility standards.
Policy alignment
University resources must be reserved for business purposes on behalf of the university. They may not be used for personal gain, and may not be used for personal use except in a manner that is incidental, and reasonable in light of the employee's duties. Please see Section 7 of the University Code of Conduct for more details.
These standards keep Stanford's information assets safe, accessible, and properly branded, and function alongside existing requirements in the Stanford Administrative Guide, specifically Memo 6.3.1 (Information Security) and Memo 6.8.1 (Accessibility of Electronic Content).
While site content is not actively monitored, Stanford reserves the right to remove content, restrict access, revoke a subdomain name, or disable a website that conflicts with policy or violates the Terms of use for sites. Stanford is not obligated to take such action.
Who this applies to
The scope of these standards applies to:
- All academic, administrative, and research units that develop or use electronic content for university business, including in the context of university operations, clinical research, academic and research unit sites, web and mobile-based applications, and marketing microsites, among others.
- All domains, subdomains, and externally hosted sites representing Stanford University. This includes web properties created by academic and administrative units, individuals (e.g., faculty, staff, or students), communities of practice, and event or conference sites using a stanford.edu or Stanford-branded .org or .com domain or otherwise representing the university.
- All partners, consultants, and vendors developing, hosting, or maintaining web content for or on behalf of Stanford.
Note: When engaging a third-party vendor, ensure all contracts include clear language that holds the vendor accountable for meeting Stanford’s security, privacy, branding, and accessibility requirements. (Get more guidance on working with a vendor.)
Ownership, Governance, and Registry
| Expectation | Description | Lifecycle Stage | Guidance and Support |
|---|---|---|---|
| Identifiable Ownership Required | Every site must have an identifiable ownership; every site must have a named business owner and a technical web administrator with a valid Stanford affiliation and email. | Planning | At project start |
|
| Approved Hosting Recommended | Site owners are encouraged to use Stanford-supported platforms; those using commercial services (e.g., Wix, Squarespace) must take on additional responsibility for manual vulnerability remediation and accessibility monitoring. | Planning | During platform selection |
|
| Workgroup Ownership Recommended | To ensure business continuity and secure access delegation, it is strongly recommended to use services that are compatible with Workgroup Manager whenever possible. Ownership can then be assigned to a Stanford workgroup rather than a single SUNet ID. | Planning | At project start |
|
Security, Data Handling, and Privacy
| Expectation | Description | Lifecycle Stage | Guidance and Support |
|---|---|---|---|
| Administrative Access Required | Administrative access to web applications must follow least privilege: access must be provisioned to individual, non-shared accounts and restricted to the minimum permissions required for assigned duties. | Build | When creating accounts |
|
| Authentication Required | All administrative logins must require Multi-Factor Authentication (MFA) or Single Sign-On (SSO). | Build | Before granting access |
|
| Credential Hygiene & Access Control Required | For user and administrative password, must adhere to the University Password Standards. Do not store API keys in version control tools like GitHub. | Operational | Quarterly |
|
| Patch & Vulnerability Management Required | All software and services in use to manage a site or application must be patched within the timeframe required per minsec standards relevant to web application and data classification of the content. | Operational | As updates are released |
|
| Activity Logging Required | Audit logs and user activity logs must be stored locally on the originating system to support incident investigations. Systems classified as Moderate or High risk must additionally follow the centralized logging requirements at https://minsec.stanford.edu/. | Operational | Ongoing |
|
| Data Minimization Required | Owners must implement data retention limits and use only approved storage locations (on-prem or approved cloud). | Operational | Ongoing |
|
| DNS Hygiene Required | Owners must perform regular DNS audits and promptly decommission obsolete records (especially CNAMEs) to prevent "dangling DNS" exploitation. | Operational | Ongoing |
|
| Encryption Required | All sites must maintain an active SSL/TLS certificate (HTTPS-only). | Launch | Before site launch to production |
|
| Secure Sunset Required | Upon decommissioning, owners must remove DNS entries, revoke all credentials, and archive or delete data per retention policies. | Retire | At shutdown |
|
| Pre-launch Checks Recommended | Consult with the University Privacy and Security Offices before launching the new subdomain. | Launch | Before site to production |
|
Brand, Content, and User Experience Controls
| Expectation | Description | Lifecycle Stage | Guidance and Support |
|---|---|---|---|
| Trademark Alignment Required | All sites must comply with Administrative Guide 1.5.4 regarding the ownership and use of Stanford’s name and trademarks. | Planning | At project start |
|
| Content Standards Required | University web properties are governed by institutional policies and principles that support inclusion, academic freedom, and appropriate institutional voice. Departmental and lab websites should avoid using discriminatory language and presenting personal views as institutional positions. Content should be accurate and regularly reviewed to remove outdated information and maintain institutional integrity. | Operational | Annually |
|
| Naming Compliance Required | Subdomain names must clearly reflect the recognized title of a university unit or service without ambiguity and must not conflict with other university interests. Approval by University Communications is required. Naming assignments via the Virtual Host service is available only to departments, research groups, and university-recognized student organizations. Virtual URLs cannot be linked to an individual’s personal webpage. | Planning | Before requesting domain |
|
| Brand Identity Recommended | The Stanford brand identity creates a distinct and recognizable look across communications. To ensure brand compliance on your website, University Communications recommends incorporating the Stanford Identity Bar, Global Footer, primary typography, primary color palette, and accessible underline link style. | Build | During development |
|
| External Link Notices Recommended | Websites should notify visitors when they are leaving a Stanford-managed property for an external vendor or site. | Build | When linking externally |
Accessibility
| Expectation | Description | Lifecycle Stage | Guidance and Support |
|---|---|---|---|
| Barrier Reporting Required | Website pages must include an "Accessibility" link (typically in the footer) that leads to a mechanism for users to report digital barriers. | Launch | Before site launch to production | |
| Scanning and Monitoring Required | Public-facing sites must be registered in Siteimprove, Stanford’s centralized scanning platform, to track and remediate issues. | Launch and Operational | Before site launch and ongoing |
|
| Technical Standards Required | All electronic content must conform, at a minimum, to the accessibility standard set forth in Memo 6.8.1 (Accessibility of Electronic Content). | Build | During development |
|
Services to Help Meet Minimum Standards
Stanford Sites
Stanford Sites is a university-supported Drupal platform designed with minimum web compliance features built in, including:
- Security & compliance: MFA/SSO authentication, automatic patching, SSL/TLS certificates, and approved hosting
- Accessibility & branding: WCAG 2.0–compliant themes with Stanford Identity Bar, Global Footer, and typography preinstalled
- Automated management: Siteimprove registration, ownership tracking, and platform updates managed by Stanford Web Services
- Access control: Stanford Workgroup integration for secure, collaborative site management
- Naming compliance: Supports both three- and four-part domain name pattern (e.g., [groupname].groups.stanford.edu, [yourname].people.stanford.edu)
Stanford Identity Guide
The Stanford Identity Guide is the official resource for Stanford's visual identity and brand standards.
Resources include:
- Stanford Identity Bar: Guidelines for implementing the required header
- Global Footer: Standard templates and required links
- Typography standards: Approved fonts and web type hierarchy
- Color palette: Official Stanford colors with accessibility guidance
- Logo usage: Proper use of the Stanford wordmark and seal
Siteimprove
Siteimprove is Stanford's centralized scanning and monitoring platform for accessibility, SEO, and quality assurance.
Capabilities include:
- Automated WCAG testing: Scans for Level A and AA compliance, prioritizes issues, and provides fix guidance
- Dashboards & reporting: Track accessibility scores, page-level issues, and improvement trends over time
- Additional monitoring: Quality checks (broken links, spelling), SEO insights, and policy compliance tracking
Definitions
The following definitions clarify the key terms and roles used throughout the Minimum Web Standards (MinWeb) to ensure consistent understanding across the university.
Approved Hosting
Website hosting platforms recommended by UIT. Some UIT-managed content management systems offer built-in security and accessibility support features (i.e., Stanford Sites and Stanford Sites Intranet), while other approved hosting options offer more limited UIT support.
Data Risk Assessment
A formal review process performed by the University Privacy and Security offices to identify potential risks before a site begins collecting or sharing sensitive information, especially when third-party services are involved. Visit dra.stanford.edu for more information.
High-Risk Data
Information that requires the highest level of protection because it is sensitive or protected by law. This includes Protected Health Information (PHI), Personally Identifiable Information (PII) like social security numbers, and financial information such as credit card or payment data.
Lifecycle Stage
Where a website sits in its overall lifespan. In the context of this minimum web standard guide, we've defined lifecycle stages as the following:
- Planning: site concept, approval, domain request
- Build: design, development, and configuration
- Launch: pre-production checks
- Operational: ongoing maintenance
- Retire: decommissioning
Minimum Requirement (red tags)
The mandatory baseline condition that must be met.
Recommended Practices (blue tags)
Non-mandatory guidelines that support or enhance compliance with the minimum requirements.
Site Owner vs. Technical/Web Admin
Site Owner (Business owner): The individual or Stanford workgroup ultimately responsible for the site’s existence, the accuracy of its content, and its overall compliance with university branding, privacy, and security policies.
Technical/Web Admin: The person responsible for the day-to-day technical management of the site, such as applying security patches, managing user access, and ensuring the site stays functional, acting at the direction of the Site Owner.Any outside partner, consultant, or vendor that provides a service for a Stanford website. Examples include external hosting providers, analytics tools (like Google Analytics), payment processors, and social media tracking pixels.
Stanford.edu Domain and Subdomain
The "stanford.edu" domain is the university’s primary internet address. A subdomain is a specific name that comes before that domain (e.g.,
departmentname.stanford.edu) used to identify a particular unit or service.Third-Party Service
Any outside partner, consultant, or vendor that provides a service for a Stanford website. Examples include external hosting providers, analytics tools (like Google Analytics), payment processors, and social media tracking pixels.
Web Content Accessibility Guidelines (WCAG) 2.0, Level A and Level AA
Technical standards for web content accessibility developed by the World Wide Web Consortium.
Web Property / Stanford Website
Any digital presence—including informational websites, web-based applications, and mobile apps—that represents Stanford University, conducts University business, or uses the Stanford name. This includes sites hosted on campus servers as well as those hosted by external vendors.
Who to Contact with Questions
| Unit / Website | Topic | Help |
|---|---|---|
| Privacy Office (UPO) | Privacy incidents, complaints, consultation | Submit help request |
| Information Security Office (ISO) | Information security questions or incidents | Submit help request |
| Stanford Office of Digital Accessibility (SODA) | Digital accessibility issues, website evaluations, tools, and training | Submit help request |
| Stanford Web Services (SWS) | Help with design, UX research, or a web development project | Request SWS consultation |
| University Communications | University-level brand inquiries | Contact University Communications brand manager |
