Digital Governance Policy

1. Objective

The primary objective of this document is to provide collaborative centralized governance for the ongoing development, deployment, delivery, and maintenance of the GSD’s public online presence and to represent the GSD brand consistently across public digital channels through standard processes, roles, responsibilities, and practices.

This objective will be pursued with the school’s underlying strategic priority in mind: to facilitate a user experience that will develop a lasting digital relationship with all visitors—particularly current and prospective students, faculty, and staff—providing them with the information they need quickly, easily, and enjoyably.

2. Governance Structure

The Digital Governance Committee is composed of the assistant dean and director for communications, the assistant dean for information services, the assistant dean for information technology, the digital project manager, the web services manager, a faculty representative, and other GSD community members who may be invited from time to time.

It is the responsibility of the Digital Governance Committee to set the direction and policies for the GSD’s public online presence and digital properties, including the school’s official website and the web operating environment, based on best practices. In order that directions and policies are set with a full understanding of the issues and impact of any given decision, decisions appropriate to the jurisdiction of the Digital Governance Committee will be reached by consensus. If the group cannot reach consensus, options will be presented to the GSD’s Executive Committee with a recommendation for resolution.

Responsibilities of Digital Governance Committee include:

• Establish appropriate policies, processes, and procedures to govern digital strategy and standards for public GSD-branded communications.
• Evaluate effectiveness of policies and standards.
• Ensure compliance with all legal and regulatory standards, including accessibility, security, privacy, etc.
• Authorize global changes to taxonomy, structure, branding, look and feel, navigation, styling, etc., as needed.
• Ensure quality, consistency, and content integrity across digital platforms.
• Facilitate and resolve non-compliance issues.
• Provide guidance for the use of web properties for the GSD community

The Digital Governance Committee will meet at least once per semester to review requests from academic and administrative stakeholders for major changes to the GSD website, other digital properties, and/or relevant policies and procedures. They will update the Dean and Executive Committee on project plans, if necessary, and disseminate information to their staff and department members, as needed.

Community members are invited to send ideas, requests, problems, and concerns to the Digital Governance Committee via email to the Web Team. Ideas, requests, problems, and concerns will be logged into a ticketing system and reviewed with the committee on a semester basis.

3. Governance Policies

The GSD’s main website, subsites, e-communications, and social media sites provide public platforms for showcasing the School’s best qualities and projecting a positive image of the School to the world. They are strategic assets that carry enormous influence and provide global access to multiple aspects of the School. With a distributed content team managing these sites, guidelines that encourage clarity, accuracy, and consistency are essential to protecting the GSD’s online image. This document aims to cover most areas of digital governance, but if you have questions that are not answered upon reviewing this document, please contact the Office of Communications.

The website gsd.harvard.edu is the sole property of the GSD. While designated staff will have access to edit certain portions of the site, create new content, and remove old content, the site and all its subdomains remain the property of the School.  Additionally, the Site Builder theme and all sites built with it are the sole property of the GSD.

Policies and Procedures for GSD Websites

A ‘GSD website’ is any website, including gsd.harvard.edu and all subsites (as defined below), that purports to represent the views and activities of the GSD community, that is owned or managed by any GSD employees or official student-organization, or that uses any GSD branding. Any such website must be approved by the Digital Governance Committee and is subject to all the requirements in this document. Please see section 4.2 on GSD subsites (below) for information about how to request approval of a new GSD-branded website.

4.1 GSD.HARVARD.EDU

Content Management System

All content is published to gsd.harvard.edu using the WordPress Content Management System (CMS). No other software product may be used within the GSD’s approved CMS and its build architecture. Additional sites, upon approval, may use the gsd.harvard.edu API when appropriate. Content editors located in offices and departments across the School are expected to regularly check all content on pages they manage to ensure that it is up-to-date and that all links are functioning correctly.

Roles and Permissions

A group of content editors, representing offices and departments throughout the School, manage the content on the website. Department and office administrators may nominate a staff member to be a content editor if they meet the criteria outlined in the GSD’s Content Editor Policy, and if their allocation of editors has not already been met. These requests should be submitted through the Content Editor Request Form. If the nomination is approved by the Web Team, the editor will be granted access to a Canvas course where they must complete the required training, after which, they will be given access to the CMS. Access will not ordinarily be granted to students, faculty, or temporary workers.

Department administrators must maintain a list of current content editors, and should contact the Digital Project Manager if an editor’s access should be revoked (e.g., when an employee changes jobs or leaves the GSD).

Editors will be assigned a contributor role that gives them access to the content areas they need to maintain their pages. Editors will not have access to areas of the site where they do not maintain content.

In addition to the contributor roles defined within our CMS,

• The Office of Communications is responsible for generating and maintaining content for the homepage and top-level landing pages, and provides content writing, editing, organization, and design guidance to departments school-wide.
• Academic chairs, department directors, non-departmental program directors, and office managers, are accountable for:
  • Providing content editors with recommendations regarding content direction for their webpages that align with the school’s strategic web goals and the established site structure.
  • Ensuring that content is accurate, up-to-date, follows best practices for web content and usability, and meets the School’s quality standards.
  • Coordinating with the Digital Project Manager to ensure that an editor is assigned and trained to maintain their pages.

Quality Control

Maintaining the quality and accuracy of the GSD website is a shared responsibility that needs to reflect the brand, mission, and values of the institution. Typos, poor grammar, outdated information, etc. detract from effective communication of what makes the GSD an outstanding place to study and work.
The GSD’s Office of Communications has access to all areas of the main website and social media channels. To ensure quality control, the Office of Communications may edit or alter content as needed, for clarity, consistency, and style, to ensure quality control and to conform with school naming conventions and branding. The GSD reserves the right to revise or delete content housed either on school resources or external resources that does not meet acceptable use guidelines, or the standards outlined in this policy.

Department and office administrators are responsible for ensuring the quality and accuracy of all content changes made on their pages. If error(s) appear on a page, administrators should contact the editor responsible for that page first, and if the error is not resolved within a reasonable time, the administrator should contact the Web Team.  If quality control issues recur, the Office of Communications will relay the concern to the editor’s manager and may suspend editing privileges until the editor completes further training.

In addition to regularly maintaining their content, editors and their supervisors are expected to carry out an annual content audit on all of their web pages. During this process, content should be updated, unnecessary pages should be unpublished, and a general review of usability and accessibility should be conducted.

Change Management and Classification of Changes

Changes to the GSD website may arise reactively in response to problems, or proactively in seeking improved efficiency or effectiveness, as well as to enable or reflect institutional goals and priorities. Change Management ensures that standardized methods, processes, and procedures are used to facilitate efficient and prompt handling of all changes and maintain the proper balance between the need for change and the potential detrimental impact of changes. Changes are classified as follows:

• Fixes: A fix can be an urgent, unplanned change (aka a “hot fix”) or a planned change that goes through the standard release and deployment process.
  • An “Emergency” is defined as a change required to immediately restore service or to avoid an outage where no other workaround is available.
  • An “Error” or “Bug” is defined as a deviation from expected behavior that does not require emergency change handling and where a workaround is available. Examples of “bugs” include incorrect data fed from third party services, inconsistent cross-browser support, errors in site search, etc.
  • An “Urgent Bug” is an error that impacts core functionality (e.g., site search), operations (e.g., course directory), or system performance, or that exposes the School to security or legal liability (e.g., Harvard Key authentication errors or failure to meet University guidelines for accessibility). Bugs should be reported via the Error Report Form.
• Enhancements: Enhancements are planned changes that go through a review and approval process.
  • A “Small” change is defined as an update to existing content. “Small” changes can be implemented directly in the content management system by an authorized editor.
  • A “Medium” change is defined as any change that impacts the information architecture, organization, and search engine results of the site. Examples of “medium” changes include modifications to site navigation, the creation of new pages, or the reorganization or renaming of existing pages. Medium changes must be implemented in collaboration with GSD Web Team members with specialized knowledge of best practices in content strategy, web usability, information security and accessibility, and search engine optimization (SEO). Medium changes may require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form.
  • A “Large” change is defined as any change that impacts the data structure, theme, or functionality of the site. Examples of “large” changes include the creation of new sections or content types; modifications to the look and feel or user interface design of the site; adding or removing attributes of a data type; modification to an existing feature; creation of a new form, feature, or interaction; integration with a third-party system or service. Large changes must be implemented in collaboration with GSD Web Team members with specialized knowledge of best practices in web design and usability, information security and accessibility, and web development, and have experience with the GSD’s custom implementation of WordPress. Large changes typically require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form.

Change Management Process

The Change Management Process begins with the identification, recording, and classification of the change, and continues with its review, approval, scheduling, development, testing, and staging for implementation. Changes must be submitted with appropriate lead-time to allow the Web Team to perform these tasks and to ensure that individuals impacted by the change receive adequate notice.

1. Request Change: All “Errors” or “Bugs” (defined above) should be reported via the Error Report Form. Errors reported via this form are automatically logged in a ticketing system and reviewed by the core Web Team. “Emergency” errors will be addressed immediately. “Urgent” errors will be scoped and prioritized upon receipt. Non-urgent errors will be scoped and prioritized along with other change requests during weekly meetings of the core Web Team. Requests for Medium or Large “Enhancements” (defined above) should be submitted via the Enhancement Request Form. Members of the GSD Web Team will review these requests in their weekly meeting and will evaluate whether the request can or should be fulfilled. Submitting an enhancement request does not guarantee that the site will be updated to accommodate the request.
2. Define Scope and Impact: Defining the scope of a change includes identifying the platforms impacted; cost of development; maintenance requirements; units or departments affected; business case or rationale for change; alignment with known strategies and stated objectives; potential conflicts; skills or expertise required to implement the change; availability of internal or external resources; and an assessment of institutional and technical risk. This data is used at many decision points within the process. Examples of questions used in assessing the risk or impact of a change:
   1. Who will the change affect?
      1. Staff resources
      2. Business units or departments
      3. End users
   2. What will the change affect?
      1. Sites, sections, or pages
      2. Platforms, systems, or services
      3. Data models, feeds, or flows
      4. Internal processes or workflows
      5. User behavior
      6. Identity, look and feel
   3. What is the impact on?
      1. Other scheduled changes
      2. Other business units or departments
      3. System design
      4. System performance
      5. Search engine results
      6. Institutional identity
      7. Other resources (budgets, staffing, security, etc.)
3. Approve, Reject, or Modify Change: Change requests will first be reviewed by the core Web Team. After review and initial scoping/risk assessment, the Web Team may either approve or reject the request. Every attempt to resolve issues or conflicts will be made prior to rejecting a change, including suggesting modifications to the scope, design, or timing of the original request. If there are questions about the appropriateness or feasibility of a request, it will be referred to the appropriate technical or communications lead for a decision. If a decision cannot be made or the requesting party disagrees with the decision, the request will be reviewed by the Digital Governance Committee, which will make the final decision.
4. Prioritize/Schedule Change: Every effort will be made to implement changes in a timely manner while recognizing the need to balance required maintenance, upgrades, and fixes with desired enhancements to existing content and functionality. Following approval of a change request, the Web Team will use their judgment to prioritize the request among other planned changes. If a change involves high risk, it may be scheduled to minimize impact (e.g., during intersession or summer break). Technical or operational interdependencies discovered during the review and scoping process may also affect timing. If the requesting party disagrees with a scheduling decision, it will be reviewed by the Digital Governance Committee, which will make the final decision.
5. Implement Change: Implementation of an approved medium or large change may only be performed by the GSD Web Team, a staff content editor working in collaboration with the Web Team, or a designated vendor. Changes will be deployed to a web staging environment for review and approval. Upon approval, the Web Team will follow the standard release and deployment process. Documentation of changes will be stored in a common location to allow for coordination among team members. Criteria for a successful change include:
   1. The change was implemented in accordance with the implementation plan
   2. The change was implemented within the planned implementation timeframe
   3. The change met anticipated objectives defined in the Change Request
   4. The change did not cause unplanned impact to business units, departments, or end users
   5. The change did not result in a system outage

Requesting URL Redirects

A URL redirect automatically forwards a user from one URL to a different URL. There are a few reasons why a redirect might be needed:

• The page or file needs a human-friendly URL for sharing.
• A logical alternative URL is needed for GSD section. 
Example: the URL https://www.gsd.harvard.edu/library/ redirects site visitors to the URL https://www.gsd.harvard.edu/frances-loeb-library/
• These requests are evaluated on a case by case basis and are implemented by the GSD’s Web Team. To request a redirect, please fill in the Redirect Request form and a member of the Web Team will get back to you within 2 business days.

4.2 GSD Subsites

A Subsite is a website that bears the school’s name or logo, or that otherwise purports to represent the opinions or work of the GSD but is not directly part of www.gsd.harvard.edu. Subsites must be sponsored (“owned” and “maintained”) by a current GSD faculty member or administrator and be related to a GSD-affiliated research unit (centers, labs, groups, initiatives, offices, etc) program, official student group, or initiative. All new GSD subsites must be approved by the Digital Governance Committee (see below). Subsites must meet the following criteria:

• Group or initiative has been officially sanctioned by the GSD.
• Provide lasting value to the school.
• Satisfy an unmet need.
• Have approval from the Digital Governance Committee.
• Have an ongoing staffing and maintenance plan.
• Demonstrate adequate funding to meet start-up and ongoing maintenance costs (if school funding is not available).
• Register relevant ownership and technical details with GSD Web Staff, enabling the Web Team to make changes in hosting plans or content, as required or needed.

Requesting a GSD Subsite

All GSD subsites must be approved by the Digital Governance Committee, regardless of what technology, vendor, or hosting provider is used. To request a new website, Sponsors or Site Owner should fill out a New Site Information Form. The request will be reviewed by members of the Digital Governance Committee. Once a decision is reached, an email will be sent to the person who submitted the form, informing them of whether the subsite has been approved or denied. The review process can take up to 10 business days, and additional information may be requested in order to make a decision. Subsite approval does not imply an approval of costs or vendor, but only that the existence of the site has been authorized.

The GSD’s Finance Office will not accept a contract related to the creation of a new subsite unless the Sponsor or Site Owner can show that the subsite has been approved by the GSD. The GSD’s Finance Office will not reimburse website costs (eg: design, development, domain name, hosting, etc) unless the Sponsor or Site Owner can show that the subsite has been approved by the GSD.

Student groups should contact the Office of Student Affairs to request approval for a new website. Once the Office of Student Affairs has granted approval, the request will be forwarded to the Digital Governance Committee for final approval. Student groups must be officially recognized by the GSD to receive approval for a subsite. Please visit the Student Group Directory for a list of active student groups.

Unauthorized Subsites

An Unauthorized Subsite is a website that purports to represent the opinions or work of the GSD or uses the GSD name or branding elements (logo, wordmark, etc), has not been approved by the Digital Governance Committee, and does not meet the requirements for a GSD Subsite set forth above. In the event that the GSD Web Team becomes aware of an unauthorized subsite, they will attempt to contact the site creator(s). If the responsible parties can’t be contacted, the Web Team may take all possible measures to assume control of the site or to have it taken down. If the unauthorized site creators are responsive, they will be advised of the non-conforming elements of the site and asked to provide a remediation plan and schedule to resolve the issues, and may be asked to immediately modify or take the site down in the interim. In this remediation, the Web Team can provide strategic guidance and technical oversight, but all costs associated with bringing the site into conformity will be borne by the site owner.

Roles

For communication purposes, people involved in the creation and maintenance of GSD subsites are assigned roles, so the Web Team knows who to contact if an issue with a subsite arises.

• Sponsor: GSD department or office that is responsible for the subsite. Manages budgets and contracts and makes decisions on the site handover or decommissioning if Site Owner leaves the GSD.
• Site Owner: GSD faculty or administrator responsible for the subsite. Responsible for goal setting, strategy & quality assurance; managing funding to support development & maintenance; overseeing continuity through personnel (staff/student/developer/consultant) turnover.
• Site Manager: Is the primary contact for the GSD’s Web Team and oversees the day-to-day management of the subsite and its content.
• Content Editor: Individual with access to the backend of the site and responsible for editing and updating content and other settings.
• Site Developer/Technical Contact: Individual or vendor involved in the build out of the site, including theming and other customizations. Technical contact for errors, upgrades, and other issues.

Every GSD subsite must have a Site Owner and Site Manager on record with the GSD Web Team, in addition to documentation including hosting details and passwords for emergency access.

Domain Names

Current GSD faculty and administrators may request a GSD subdomain name (e.g., mysite.gsd.harvard.edu or research.gsd.harvard.edu/mysite) for a subsite related to a GSD-affiliated research center, lab, program, course, or initiative.

A vanity domain name (e.g., “mysite.com” or “mysite.org”) may be used as an alias. Upon request and availability, the GSD Web Team will purchase a vanity domain on your behalf, set up the Domain Name System (DNS), and bill your group or department for the cost of the domain annually.

A GSD subdomain name may not be used for personal sites or portfolios. Individual faculty members wishing to use a harvard.edu domain for personal use should request a site on a platform managed by Harvard Web Publishing.

To request a GSD subdomain name, site owners should fill out the New Site Information Form.

Harvard University Subdomains

All Harvard domains are managed by Harvard University Information Technology (HUIT). The GSD requests domain names from HUIT and is subject to HUIT’s workflow and approval processes. Although requests are often processed quickly, please allow at least several business days for domain name changes.

Student groups may not use a GSD subdomain name and must purchase their own domain name (e.g., mystudentgroup.org) through a domain registrar (e.g., aws.amazon.com). Note that student groups must obtain advance permission to use any form of “Harvard” or “GSD” in an internet address. Student Groups should contact the Office of Student Affairs to request permission.

A Harvard subdomain name (e.g., “mysite.harvard.edu”) may be requested for websites sponsored by inter-school groups and programs. Please contact GSD Web Staff for assistance requesting a Harvard domain name.

Web Hosting

The Web Team manages web servers for the GSD’s primary website and subsites. Only WordPress-sites are hosted on these servers (installed, updated, maintained, and hosted). The GSD prefers to host all subsites on GSD-managed servers, however, exceptions can be made if approved in advance. Typically, exceptions are approved if there are valid reasons why the subsite cannot be hosted on a GSD-managed server, for example, the website is not built in WordPress, or there are technical reasons why the GSD cannot support the site.

We have partnered with a third-party vendor to provide basic system administration and support for subsites hosted under the GSD’s domain name. Web hosting accounts are managed by the GSD’s Web Team. Any associated costs will be billed directly to the requesting group or department.

External consultants or vendors may be given access to site administration tools after requesting Sponsored Role status from Harvard University Information Technology (HUIT).

Non-WordPress Sites

For some special purposes, WordPress may not be a satisfactory medium for web design or hosting. In the rare event that an authorized GSD subsite requires a CMS other than WordPress, it may be permitted only by consent from the Digital Governance Committee. Such consent will be granted only in extraordinary circumstances, where the GSD’s existing technologies do not adequately meet the needs of a project that has been determined to be worth the costs to the School of engaging new technologies to enable it. In such a situation, the site owner must agree to bear all costs of ensuring the new subsite is otherwise continuously compliant with this policy and all costs related to ongoing maintenance of the site. Furthermore, the platform must adhere to Harvard’s digital security requirements, and must be approved by Harvard’s Digital Accessibility Services group as adhering to Harvard’s Digital Accessibility Policy. The GSD Web Team must be given access to the CMS and hosting platform (where applicable) for non-WordPress sites.

Security

All GSD websites must comply with Harvard University’s Information Security Policy. Confidential information may require authentication via Harvard Key or other conditions. Please review the following policies:

• Harvard University – Information Security
• Harvard University Information Technology – Security Policy

Accessibility

All GSD websites and applications must comply with Harvard University’s Accessibility Policy. Site owners must incorporate accessibility into their development roadmap whenever applications are scheduled for a minor or major upgrade. Developers and content creators must unit test their code and/or content for accessibility. In addition, accessibility testing should occur as part of the test environment to stage environment deployment process. Any accessibility issues identified must be remediated before the application can move to production.

Vendor contracts for web/application development or hosting must conform to WCAG 2.2, Level AA guidelines and include the Accessibility Rider (OGC Model Documents webpage).

It is expected that any accessibility issues identified through testing or end user feedback will be fixed within 12 months. For complete requirements, please view:

• Harvard University Information Technology (HUIT) Accessibility Policy
• Harvard Web Publishing Accessibility Guidelines (requires HarvardKey)
• Harvard University Information Technology (HUIT) Disability Services – Online Accessibility
• For requirements related to the development of mobile applications, see Harvard Web Publishing Mobile Technologies Guidelines (Requires Harvard Key)

Digital accessibility must be monitored throughout the life of a subsite. HUIT offers all “Harvard employees working on public-facing websites for Harvard” access to Site Improve, an online accessibility tool that provides reports on WCAG 2.2 compliance. Site owners should request access to Site Improve through HUIT  so they can continue to audit and maintain their site’s compliance.

If the GSD’s Web Team discovers a subsite is not in compliance with Harvard’s accessibility policy, the Site Owner will be notified, and will have 3 months to resolve the issue. If the site’s accessibility is not brought into compliance in that time, or if a good faith effort has not been made, the Web Team will report the site to the HUIT’s Digital Accessibility Services team for further review and action.

Design

For high-profile subsites, the GSD reserves the right to require the Site Owner to hire a professional web designer for the project. This will ensure the site meets design, usability, and accessibility standards.

Even when hiring an outside designer, Site Owners may use the free GSD Site Builder platform to build their site. This will be a much cheaper alternative to building the site from scratch.

Content

It is the responsibility of the Site Owner to ensure that content is fresh, accurate, and up to date; complies with University guidelines for Information Security and Accessibility; and follows University guidelines for media capture and usage:

• Photography & Video of Harvard Buildings & Facilities
• Media Relations Policies
• Copyright and Fair Use: A Guide for the Harvard Community

Content editors are expected to ensure that all links are live, tested, and appropriately implemented.

To prevent the dissemination of conflicting information, subsites must not duplicate official school information. Rather, they should link to the authoritative source. Official school information includes but is not limited to:

• Tuition, fees, and scholarship information
• Academic requirements
• Academic calendars and deadlines
• Course descriptions and schedules
• GSD’s mission statement, community values, policies and procedures, etc.

Please consult with the Office of Communications for guidance.

Maintenance

It is the responsibility of the Site Owner of any GSD website to ensure that all technical details of web hosting, including credentials for administrative access, are provided to GSD Web Staff, to enable ordinary administrative access for maintenance and otherwise as required.

It is also the responsibility of the Site Owner to ensure the site is in good working order, including performing regular software updates, testing the site after updates, ensuring working backups of the site and its data, and reporting errors to an external vendor or GSD Web Staff. All subsites must comply with University guidelines for Information Security and Accessibility.

If the site has been built or customized by an external vendor, that vendor is responsible for ongoing maintenance. The Site Owner must have an ongoing maintenance contract with this vendor. The Site Owner may find an equally qualified vendor to take on this responsibility. Additionally, the vendor must provide the Web Team with documentation, including a user manual, technical specifications, a description of the software/site/server, and contact details. All maintenance costs associated with ongoing maintenance activities are the responsibility of the Site Owner.

Decommissioning and Archiving

GSD Web Staff review all subsites annually. Any site that has not been updated in 12 months will be scheduled for decommissioning. A good faith effort will be made to contact the last known Site Owner. If the Site Owner cannot be reached, the Site Sponsor (department or office) will be contacted for a decision. If the Site Sponsor wants the site to remain online, they must provide a content plan outlining when the site will be updated and who will maintain it. To request decommissioning of a subsite, the Site Owner should contact GSD Web Staff.

In some circumstances, the Digital Governance Committee may decide to decommission a subsite even if the Site Owner wants it to remain online. The reasons why this could occur include:

• The site runs on outdated software that can no longer be supported by the GSD because of security risks.
• Accessibility concerns have not been addressed.
• The site is several years old, and its information no longer offers enough value to justify the resources and cost to support it.
• Analytics show that fewer than an average of 30 visitors per month are coming to the site and therefore it is time for it to be decommissioned.

In these cases, Site Owners and Site Sponsors will be provided with an email from the Digital Governance Committee explaining the decision, three months before the site is decommissioned.

Decommissioned sites are not automatically archived but may be eligible for archiving by Harvard Library. Site administrators wishing to request archiving of a site should contact the GSD’s Collection Management Archivist.

Personal Sites – Faculty

Personal websites are not considered GSD subsites and will not be supported by the GSD’s Web Team. Personal websites promote an individual’s accomplishments, research that is unaffiliated with the GSD, and/or personal opinions. These sites cannot purport to represent the GSD or use GSD branding to identify them. Personal websites do not have to be registered with the GSD’s Web Team.

Certain community members wishing to create a personal website may qualify for a site on a platform managed by Harvard Web Publishing. The GSD Web Team cannot offer support on these sites.

Eligible community members include:

• Faculty members (excluding annual visitors)
• Research associates (full-time)

Students, staff, visiting postdocs, and visiting scholars do not qualify for a Harvard Web Publishing site. Please note that there are a limited number of Harvard Web Publishing sites available to the GSD. Personal sites on Harvard Web Publishing platforms will need to comply with HUIT’s Terms of Use.

Personal Sites – Students

Students interested in creating a personal portfolio site should contact Career Services for information on platforms and best practices. The GSD Web Team cannot support any student portfolio sites and this policy does not cover any personal websites.

5. Student Content

Web content about students is protected by and must comply with FERPA regulations.  All departments, programs, labs, courses, and other groups who wish to publish student names, contact details, or biographies on the GSD’s publicly-available websites, subsites, or social media accounts should reference the GSD’s Student Handbook for guidelines.

All student work that is published must be credited accurately.

Students and Alumni may request to have their information or projects removed from any websites or subsite by contacting the Site Owner, Site Manager, or Site Editors.

6. Social Media

Individual programs or groups wishing to establish a social media presence should contact the Office of Communications for assistance. All social media sites bearing the Harvard or GSD name must comply with guidelines set forth by the Provost’s office, review Harvard Public Affairs & Communications’ Social Media Guidelines, and owners of such social media accounts are encouraged to complete a short training module about those guidelines.

Social media sites must be accessible by the Office of Communications for auditing purposes and will be subject to regular review. Vulnerabilities identified shall be remediated by the channel owner in a timely fashion. It is the responsibility of the channel owner to ensure accounts are in good standing and that all content complies with University guidelines for media capture and usage:

• Photography & Video of Harvard Buildings & Facilities
• Media Relations Policies
• Copyright and Fair Use: A Guide for the Harvard Community
• Social Media Accessibility Best Practices

6. Emergency Action

The Digital Governance Committee (DGC) may at any time require immediate action to change or remove any element of any GSD website, social media posting, or other digital communication. In such a case, if a good-faith effort to contact the Site Owner cannot be accomplished in sufficient time, in the judgment of the DGC, GSD Web Staff and Office of Communications staff are authorized to take all technical and other steps necessary to try to implement the necessary change. GSD Web Staff and the Office of Communications are at all times authorized to take any steps necessary to protect the integrity of the GSD’s web presence or the school’s reputation, without DGC approval.

7. Artificial Intelligence (AI)

All digital communications and content must conform to the University’s AI Guidelines.

8. Contacting the Digital Governance Committee

Community members who need to contact the Digital Governance Committee should fill in the Digital Governance Committee Contact Form. Members of the Committee will review the submitted form and will respond within 3-5 business days. If necessary, the request will be discussed at the next Committee meeting.