Supplier Information

Anti-Corruption Standards

You will not take any action that would violate the United States Foreign Corrupt Practices Act, the UK Bribery Act 2010, any anti-corruption or similar act of any country applicable to your activities, and any rules or regulations thereunder, and any established corporate policies of McGraw Hill regarding foreign business practices ("Anti-Corruption Laws") or these Anti-Corruption Standards. As one of McGraw Hill's suppliers, you and your employees, agents and affiliates will comply with these Anti-Corruption Standards.

Anti-Corruption Laws.
You will comply with Anti-Corruption Laws. You will not take any action that would cause you to be in violation with Anti-Corruption Laws, including, without limitation, the use of any corporate funds for unlawful contributions, gifts, entertainment or other expenses or payments relating to political activity; making, attempting to make, offering, or authorizing any unlawful payment, thing of value, bribe, rebate, payoff, influence payment, kickback or other similar unlawful payment to a "Foreign Official" (including, without limitation, any officer or employee of a government at any level or of a controlled enterprise thereof or of a public international organization, or a person acting in an official capacity for or on behalf of any such government or public international organization, or a candidate for political office, or a political party or party official), for the purpose of influencing an act or decision (including a decision not to act) or inducing such a person to use his or her influence to affect any such governmental act or decision to obtain, retain, or direct any business or otherwise as prohibited by any applicable Anti-corruption Laws.

Gifts.
You will not give or promise to give anything of value either directly or indirectly to any person to improperly obtain or retain business, gain improper business advantage or improperly influence any business decision. This prohibition applies whether the intended recipient works in the public or private sector. You will not accept or agree to accept anything of value in exchange for influencing a business decision or where the recipient would be placed under a real or perceived obligation to the giver.

Record Keeping.
You will not make false or misleading entries in your books (including entries that fail to reflect improper transactions), make entries that are falsified to disguise improper transactions or fail to record payments made by or to you.

Audits.
McGraw Hill may select an independent third party to conduct an audit to certify that you comply with these Anti-Corruption Standards, as set forth in the audit section of the agreement(s) between you and McGraw Hill regarding your provision of services to McGraw Hill.

Supplier Status.
You are not owned wholly or in part by a government, any agency or instrumentality thereof, or any government official. None of your owners, partners, officers, directors, or employees, or any of your affiliates is an official or employee of the government or affiliated with an individual or entity that is on the United States Specially Designated Nationals List (SDN). You will provide written notice to McGraw Hill if your status changes.

Reporting Breaches

Any failure to comply with McGraw-Hill's Supplier Code of Business Ethics or Anti-Corruption Standards should be reported to McGraw-Hill immediately.

If you have reason to believe that a supplier working on behalf of McGraw-Hill may have violated McGraw-Hill's Supplier Code of Business Ethics or Anti-Corruption Standards, or otherwise have reason to believe that such person has engaged in ethical or legal misconduct, report such violations to McGraw-Hill at –

1-888-415-8381 (US).

Or

https://hotline.mheducation.com

To the extent possible, any report submitted to McGraw-Hill will be treated as confidential and anonymous.

Technology Standards for Third Party Developers on AWS

Cloud Standards

Hosting

Unless the software solution is delivered as a fully SaaS solution, McGraw Hill requires that all components be hosted on a McGraw Hill owned AWS cloud account within our AWS organization. 

• McGraw Hill utilizes AWS Organizations and Control Tower to group related applications into separate account structures. There will be one production and one non-production account provided. All software development activity must occur exclusively in the non-production account. 
• All web applications or services relying on HTTP protocols must be delivered via a McGraw Hill owned domain name. No third-party domain ownership is permitted.
• McGraw Hill utilizes a split-DNS model where non-production sites are not exposed to the public internet and operate on an internal-only domain accessible only by VPN.
• If AWS does not provide a service or capability that meets the business objective, McGraw Hill will support Azure services. Written approval to utilize Azure is required.
• Access to AWS is provided by McGraw Hill through an Okta-controlled account. Developers will authenticate via Okta to an AWS SSO landing page or access key.
• McGraw Hill utilizes three tiers of access policy when granting IAM user access via Okta. Requests are submitted and tracked via MH Assist:
  • Read Only: Can view most AWS services. 
  • Protected: Write permissions for common services such as EC2, RDS, or S3. 
  • Power User: Most AWS services are configurable, with the exception of network or account-level controls. 
• If the solution requires a server, McGraw Hill provides several base AMI instances, and only McGraw Hill-provided AMIs are permissible. AMIs are required to be rotated monthly. The following types are available: 
  • ECS Base AMI for ECS applications
    • AL2023 AMD64
    • AL2023 ARM64 (Graviton)
  • EKS Base AMI for EKS clusters
  • Amazon Linux 2023 (AL2023) for non-containerized workloads:
    • AMD64
    • ARM64 (Graviton)
  • Windows AMI for Microsoft Windows.

Tagging

In order to perform proper automation and cost reporting, McGraw Hill mandates the use of cloud asset tags applied during asset creation, typically via Terraform. Required tag keys and valid values will be provided to the supplier at engagement onboarding.

Development Lifecycle

• Software is required to be tested and promoted via test environments. The best practice is DEV → QA → PROD.
• We enforce prod/non-prod isolation. Production services are not permitted to call endpoints registered within a non-prod account, nor are non-prod services permitted to utilize production services unless an exception is granted.

Automation

• While hand-provisioning of cloud resources is expected in a sandbox, once an application begins participating in the SDLC, we require the use of infrastructure-as-code automation. We have standardized on Terraform and provide a number of shared modules for the most commonly supported container-based hosting patterns (e.g., ECS or EKS, Serverless, ALB, CloudFront, API Gateway, Aurora or RDS, OpenSearch, ElastiCache, and other common AWS services). We also support Terraform in Azure. 

Authentication

• AWS logins are least-privilege based. We register you with AWS SSO, which creates chained IAM users. You will be grouped in either read only (limited console view), protected (you can start/stop most common services), or power user (most activities permitted). We utilize AWS Organizations, which includes Control Tower and SSM as a governance wrapper, so any action that would result in network or security changes placing an account at risk is prohibited and prevented as part of account guardrails. 
• Users in Azure are provisioned on an as-needed basis, with permissions crafted around the business case and subscription access likewise scoped.
• All access is audited and monitored. 

Network Controls

The application will be deployed into a segmented AWS account that connects to McGraw Hill's enterprise network fabric via AWS Cloud WAN, our centrally managed wide-area network service. All accounts in McGraw Hill utilize pre-provisioned network segments. These are centrally managed to ensure the stability and reliability of McGraw Hill's enterprise infrastructure and are immutable. Each AWS account contains three public and three private subnets spread across availability zones. Network CIDRs are constrained to /21 or /22 segments. Requirements for larger network segments should be carefully planned and negotiated with Cloud Operations and Engineering.

• As an established best practice, all software deployments must utilize HA configurations spread across three availability zones to ensure reliability. This requires a minimum of two instances across two availability zones to guarantee redundancy. More complex applications may require instances spread across all three availability zones to ensure Raft consensus. [1]

Software Development Standards

McGraw Hill prefers and supports open-source language frameworks. Supported server-side languages include Java, Node.js, PHP, and Go. Angular is the primary client-side framework. Data functions are supported by Python or Scala.

Utilization of McGraw Hill Shared Services

McGraw Hill operates a shared technology microservice architecture that all customer-facing applications are required to utilize directly or through an LTI implementation wrapper. This platform provides common, reusable services exposing REST endpoints acting upon a single educational entity. McGraw Hill has standardized on an asset identification standard known as "XID," which serves as a globally unique identifier. Applications are not to develop their own implementations of these common services and must instead utilize the McGraw Hill shared platform.

A full list is available outside of this document, but a common subset includes:

• Login and Landing Page: McGraw Hill has a common login flow for all customers. No web application shall create a unique login experience unless specifically authorized in the SOW.
• Video Playback: Accessible and flexible video playback support.
• IDM (user management), ORG (educational hierarchies such as district/school)
• Roster (section/class), Product (digital representation), Entitlements (license/consumption)
• Scout (service configuration utility), Tass (service and user session tokens), LTI interoperability wrapper suite

All microservices emit data through events onto a data backbone. New applications may subscribe to topics if required to cache data and respond to state changes. Otherwise, all calls are to be made synchronously. No PII data may be stored in the third-party application unless approved in writing.

Application design and architecture is expected to adhere to industry best practices as expressed by the Twelve-Factor methodology. System architecture and flow diagrams are required and must be reviewed and approved by McGraw Hill designated staff.

1EdTech Learning Tools Interoperability (LTI)

Product requirements may dictate that the software component be delivered as an LTI Tool. For external LMS platform integrations, McGraw Hill provides a 1EdTech-certified LTI Advantage integration service, which internal tool providers access via the LARS integration service. LARS provides all LTI Advantage integration capabilities and services via an LTI-compatible integration layer that supports multiple LTI versions and security frameworks. Most McGraw Hill platforms are LTI 1.3 compatible. LTI 1.3 compatibility may be utilized in place of the shared service API integration. Adapter frameworks are available to serve as an abstraction layer between third-party software components and LTI services.

Build and Configuration Management

• All build, compilation, test, validation, and deployment into a cloud platform must occur via continuous integration jobs orchestrated by GitHub Actions.
• All artifacts produced by these builds must be stored in JFrog Artifactory, a private container/artifact repository hosted by McGraw Hill. These artifacts will be scanned during storage to ensure they are malware- and virus-free. Teams are expected to utilize SonarQube with the OWASP Top 10 plugin for static security scans.
• Release communication and validation is managed via the Jira ticketing system. Any production changes must follow the McGraw Hill change control process.
• Database deployments are automated and managed within source control.
• All environments use the same build artifacts; configuration is injected by the environment.
• Builds and deployments must not incur downtime in production.
• When developing solutions for an existing platform, the delivered solution shall adhere to the lint rules established for the target platform.

Security

• End-to-end encryption is required. Data must be encrypted in transit and at rest in both addressable storage and offline backups.
• Software is scanned for common vulnerabilities through a combination of static and dynamic scanning. This begins once the software is deployed into a non-production environment and has an endpoint available for scanning. The supplier will coordinate with the McGraw Hill Cybersecurity intake process to provide credentials for test scans. Severity 1 and Severity 2 defects must be remediated prior to production promotion.
• Additional penetration testing exercises are performed by a third party and may result in additional issues requiring remediation.

Instrumentation and Telemetry

• All running software must be observable. The preferred vendor-neutral approach is to utilize OpenTelemetry and FluentBit/D for log shipping. We currently utilize New Relic as our primary APM platform. If software is not yet instrumented, it is a requirement to install New Relic agents for host monitoring and to establish Synthetic tests. Web delivery systems must install the New Relic browser beacon, as well as the Pendo agent if integrating with a licensed platform.
• Log stream data is routed to Datadog, our logging platform.

Service Level Objectives

In order to objectively measure software quality and end-user experience, the following golden signal indicators are utilized and measured over a rolling 30-day period:

• Latency: Applications must perform with less than 3.0 seconds of observable render latency as measured from Largest Contentful Paint (LCP) in the browser DOM. Synchronous services are expected to resolve an HTTP transaction in less than 500ms, with 100ms as the target mean. These thresholds must be achieved 95% of the time.
• Error Rate: HTTP responses outside of 2xx or expected 4xx normal flow codes must not exceed 1%.
• Uptime: Applications are expected to be available with successful responses at a rate of 99.95%.
• Security: Applications are required to be free of Critical and High CVE vulnerabilities. Any security defect rated P3 or higher must be resolved.
• Cost Efficiency: Applications are required to achieve the four standards above while striving to minimize operating costs. This is measured by the cloud provider's cost optimization tooling. Applications are evaluated for cloud-native scaling behavior where workload costs should closely mirror transactional volume driven by user interactions.

Source Control

Unless otherwise stipulated in the mutually signed Statement of Work, the following conditions apply:

• All source code developed for McGraw Hill LLC must reside in the corporate GitHub Enterprise account and become the sole property of McGraw Hill. Source code includes application code, configuration, Terraform, and any other textual configuration files necessary to compile, test, and deploy software to a cloud environment.
• Developers committing code to GitHub must use individually named accounts protected by Okta. Shared accounts are not permissible.
• Do not store secrets in GitHub. Use AWS Systems Manager Parameter Store or AWS Secrets Manager.
• Unit tests of sufficient coverage (80% minimum recommended) are required to enable automated deployment verification.