APN Partner Central

AWS Managed Service Provider (MSP) Program

MSP Validation Checklist 8.0

Validity Period: August 2026-February 2027

This version of the checklist was released on August 20th, 2026. The next version of this checklist is expected to be released in February 2027. AWS Partners may continue to use this version of the checklist until May 2027. AWS Partners may submit applications using the previous release (February 2026) until November 18th, 2026. Please review the change log for a list of changes (if any) since the previous version.

Self-assessment Spreadsheet

Introduction

The Amazon Web Services, Inc. (AWS) Managed Service Provider (“MSP”) Program Validation Checklist (“Checklist”) is intended for AWS Partner Network Partners (“AWS Partner(s)”) who are interested in applying for the AWS Managed Service Provider Program (“MSP Program”). The goal of the MSP Program is to recognize AWS Partners that provide the best AWS Cloud managed services experience for their customers across the full customer engagement lifecycle.

Validation Checklist Version 8.0 is the AI-First release of the MSP Validation Checklist. It raises the bar from “can you manage cloud infrastructure?” to “can you prove AI-driven delivery at scale with measurable business outcomes?” AI and agentic capabilities are interwoven into every section, and a number of AI controls that were previously Recommended are now Required. The checklist is organized into six sections — Business, People, Governance, Platform, Security, and Operations — covering 61 controls (17 Prerequisite and 44 Technical Validation).

VCL 8.0 has an effective pilot date of 21 August 2026 and supersedes VCL 7.1 starting 1 January 2027. VCL 7.1 remains valid for audits and renewals through 31 December 2026.

AWS Partners undergo a Technical Validation of their capabilities upon meeting all the mandatory Prerequisite Controls. AWS leverages in-house expertise and a third-party firm to facilitate the Prerequisite and Technical Validation. AWS reserves the right to make changes to this document at any time and without notice.

MSP Program Process Overview

The high level process for applying to the MSP Program involves the following steps:

  1. Read this document to understand the program requirements before applying.
  2. Fill out and submit the self assessment spreadsheet linked at the top of this webpage.
  3. AWS MSP team reviews the pre-requisite controls on the spreadsheet and may request additional information.
  4. Once the pre-requisite controls are approved, ISSI (third party audit firm) will contact the partner to schedule and perform the final technical validation.
  5. The results from the ISSI audit are reviewed by the AWS MSP team after the partner resolves any open action items.
  6. AWS MSP team makes a final decision, and the partner joins the MSP program if approved.

Checklist Updates

This document, as well as the AWS MSP Program, are updated regularly to account for new best practices, feedback from partners, Specialization Program changes, and new service capabilities. To provide predictability in the update process, major updates follow the format X.0 (example 8.0) and contain new or significantly changed controls that will become the officially recognized version within 90 days of release. Minor updates, in the format X.y (example 7.2) contain clarifying language and minor updates to existing controls, and may be immediately used for audits. The AWS MSP Program team will always communicate upcoming changes, both major and minor, to partners in advance of their launches.

Validation Checklist Version 8.0 is a major release that has new and updated controls, and preserves the core framework from the previous version. See the change log in Summary of Changes or at the top of the page for details. VCL 7.1 remains available for audits and renewals through 31 December 2026; VCL 8.0 supersedes it starting 1 January 2027.

The AWS Managed Service Provider (MSP) Program Full Audit process has now moved to a hybrid model, where certain controls have been designated as Prerequisite Controls. These Prerequisite Controls must be met by the partners before they can proceed to the Technical Validation stage.

Prerequisite Controls: Under the new hybrid audit model, the partners are required to meet specific Prerequisite Controls first. These Prerequisite Controls can be worked on offline using the Validation Checklist 8.0 Self-Assessment Spreadsheet, and the partners must submit the necessary evidence and documentation to the AWS MSP Program team (aws-msp@amazon.com) at least 30 days in advance of their desired date for the Technical Validation.

For any attachment or documents submission, please work with your PDM to have an AWS Box folder created, and upload the documents there. Put the link in appropriate "Partner Response" section of the Self-Assessment Spreadsheet. Alternatively, create a folder in your preferred file sharing app and share the link and credentials in the Self-Assessment Spreadsheet. Note that all materials submitted as part of the Prerequisite Controls will be viewed and evaluated by AWS employees only. The 3rd party auditor will not have access to the Box folder or the assets shared.

For each Prerequisite Control, evaluate if the evidence you gathered satisfies the Checklist requirements, and mark “Met” or “Not Met” in the “Met?” column next to the Control. If partners are unclear if they have sufficient evidence for a Prerequisite Control, or need direct support from the AWS MSP team on a Control, write “Help Needed” in the "Partner Response" column instead.

The Prerequisite Controls are designed to ensure that the partners have a strong foundation in place before moving forward with the more comprehensive Technical Validation. This approach allows the partners to focus on addressing the essential requirements upfront, streamlining the overall audit process.

Technical Validation: The Technical Validation stage of the AWS MSP Full Audit will be conducted by a third-party firm. This Technical Validation will be a one-day process, where the auditors will thoroughly assess the partner's capabilities, processes, and compliance with the remaining controls in the AWS MSP Validation Checklist.

The partners must ensure that they have adequately prepared for the Technical Validation by addressing the Prerequisite Controls and providing all the necessary documentation and evidence to the AWS MSP Program team within the specified timeframe. Additionally, partners must also complete the “Met?” evaluation column in the Technical Validation section of the Spreadsheet. For each Technical Validation Control, consider if you will be able to gather enough evidence to satisfy it during the Live Audit session, where it will be thoroughly assessed by the auditor, and mark “Met” or “Not Met” in the column. If partners are unclear if they have sufficient evidence for a Technical Validation Control, or need direct support from the AWS MSP team on a Control, write “Help Needed” in the "Partner Response" column instead. Note you do not need to provide the evidence yet, this is meant to ensure partners have read and understood all Controls.

This hybrid approach to the AWS MSP Full Audit aims to enhance the efficiency and effectiveness of the evaluation process, allowing partners to focus on the most critical areas upfront and streamlining the Technical Validation stage.

Partners are encouraged to reach out to the AWS MSP Program team (aws-msp@amazon.com) or to their Partner Development Managers (PDMs) for any clarification or assistance regarding the updated Full Audit process and the Prerequisite Controls.

AWS Managed Services Provider Program Requirements

The following items must be met before scheduling the MSP Program Full Audit (defined below) for any net-new applications to the program and full audit renewals.

  1. APN Program Requirements

    1. AWS Service Partner Tiers

      Advanced or Premier tier AWS Services Partner view requirements.

  2. Example AWS Customer Deployments

    1. Customer Case Studies

      At least 4 AWS customer Case Studies, including at least 2 that are public. See the Definitions section for requirements.

  3. Linking AWS Partner Central and AWS accounts

    1. AWS Partner Account

      The Partner's AWS Partner Central Account must be linked to their AWS account. This gives partners access to new features and APIs for AWS Channel Partners released in 2025.

  4. AWS Solutions Provider Program (SPP)

    1. End User Reporting

      If a partner is enrolled in the SPP Program, they are required to maintain > 90% compliance with end user reporting requirements. Note that enrollment in the SPP Program is not a requirement/prerequisite for the MSP application.

  5. Self-Assessment

    1. Checklist Self-Assessment

      AWS Partners should complete the Self-Assessment Spreadsheet linked at the top of this page, prior to submitting a program application or before scheduling the full audit for renewals.

      For new applications: Upload your completed Self-Assessment to your application in AWS Partner Central. Please see the AWS Specialization Program Guide for detailed instructions.

      For renewing MSP partners: Send your completed Self-Assessment Spreadsheet directly to aws-msp@amazon.com at least 30 days ahead of your scheduled audit.

      For any attachment or documents submission, please work with your PDM to have an AWS Box folder created, and upload the documents there. Put the link in appropriate "Partner Response" section of the Self-Assessment Spreadsheet. Alternatively, create a folder in your preferred file sharing app and share the link and credentials in the Self-Assessment Spreadsheet. Note that all materials submitted as part of the Prerequisite Controls will be viewed and evaluated by AWS employees only. The 3rd party auditor will not have access to the Box folder or the assets shared. Partners who do not feel comfortable sharing some evidence due to privacy, security, regulations, compliance, etc may schedule a call with an MSP reviewer to review this evidence. If this option is needed, please discuss this with your PDM before submission.

      For purpose of organization, please separate your documentation folder into folders for individual controls. The MSP team recommends the following folder structure, although it is not strictly required.

      
                            Prerequisites/
                            ├── BUSP/
                            │   ├── BUSP-001/
                            │   │   ├── Doc1
                            │   │   └── ...
                            │   ├── BUSP-002/
                            │   └── ...
                            ├── GOVP/
                            │   ├── GOVP-001/
                            │   │   ├── Doc1
                            │   │   └── ...
                            │   ├── GOVP-002/
                            │   └── ...
                            └── PEOP, PLATP, etc
                            
                            Requirements/
                            ├── BUS/
                            │   ├── BUS-001/
                            │   │   ├── Doc1
                            │   │   └── ...
                            │   ├── BUS-002/
                            │   └── ...
                            ├── GOV/
                            │   ├── GOV-001/
                            │   │   ├── Doc1
                            │   │   └── ...
                            │   ├── GOV-002/
                            │   └── ...
                            └── PEO, PLAT, etc
                            
                            AWS Managed Service Provider (MSP) Program Self-Assessment.xlsx

      Partners are required to provide comprehensive responses to the Prerequisite Controls, including all relevant documentation and supporting links. For the Technical Validation controls, partners are only required to indicate whether the control is "Met" or "Not Met." The Technical Validation controls will then be thoroughly assessed by the auditor during the one-day audit process.

      It is highly recommended that AWS Partners have their Solutions Architect, PDR and/or PDM review their completed Self-Assessment before submitting to the MSP Program team. The purpose of this is to ensure your AWS team is engaged and working with you to provide recommendations prior to the audit and to help ensure a positive audit experience.

Expectations of Parties

It is expected that AWS Partners will review this document in detail before submitting an application for the MSP Program, even if all of the program requirements are met. If items in this document are unclear and require further explanation, contact your AWS Partner Development Representative (PDR) or Partner Development Manager (PDM). Your PDR/PDM will contact the MSP Program Team if further assistance is required.

When AWS Partner is ready to submit an MSP Program application, AWS Partners must complete the “Self-Assessment Spreadsheet” linked at the top of this page. The application steps in AWS Partner Central will be the same for AWS Competency or AWS MSP. For more details on the application steps listed below or refer to the Program Guide.

  1. Go to Programs
  2. Go to Program Applications
  3. To create a new application, click “Create”
  4. Select AWS Managed Service Provider (MSP) Designation
  5. Attach an Offering
  6. Attach Case Studies
  7. Designate a Point of Contact and attach documentation
  8. Submit and track your application

image info
image info

AWS will review the application and respond back with any questions within 10 business days and provide information on how to schedule a Process and Controls Overview, if desired, and Full Audit (as defined below).

AWS Partners who have their application approved to move to the next step will have the option to undergo a Process and Controls Overview with ISSI (AWS’ 3rd party auditor) to prepare for the Full Audit. This is optional, not required. The Process and Controls Overview is a remote session, conducted using your preferred conferencing platform. The duration is 4-6 hours. The first 1-2 hours will be focused on the audit process, including best practices for preparing documentation to satisfy the Checklist controls. The remainder of time will be used for the partner to discuss the audit requirements in the current version of the AWS MSP Program Validation Checklist and understand the required evidence with an experienced third-party MSP auditor. It is not a review of prepared materials, or a deep dive into specific controls.

Additional Audit Readiness Resources: Partners may engage third-party consulting firms available through AWS Marketplace and other channels to help prepare for the Full Audit. These firms offer services such as gap analysis, remediation roadmaps, evidence preparation, mock audit rehearsals, and practice-building enablement. Examples include:

  • AssurePrime — AI First MSP Practice Building & AWS MSP Audit Readiness Training, including maturity assessments against the validation checklist, control heatmaps, audit-grade documentation, evidence dossiers, and full mock audit rehearsals.
  • MontyCloud — Audit Readiness & MSP Program Preparation Services, delivered through their CloudOps tooling.
  • Platformr — MSP Validation Preparation & Practice-Building Support, delivered through their Cloud Management Platform. These engagements are fully optional and separate from the required ISSI-facilitated Full Audit. Partners contract directly with these firms and costs vary by engagement scope. Leveraging these resources can help partners identify gaps, build audit-grade controls, and enter the Full Audit well-prepared.

AWS Partners will then undergo a one-day audit of all items in the Technical Validation section of the Checklist and their capabilities. AWS Partners accepted into the MSP Program will be required to undergo a Full-Audit renewal every 36 months thereafter. AWS Partners should prepare for the Full Audit by reading the Validation Checklist, performing a Self-Assessment using the Checklist and addressing all the Prerequisite Controls, the "Met" / "Not Met" column of the Technical Validation, and gathering and organizing objective evidence to share with the auditor on the day of the audit. AWS Partners should ensure that they have the necessary content to share any information provided in objective evidence or displayed in a demonstration. AWS will leverage an objective, third-party auditing firm: ISSI, to facilitate both the Process and Controls Overview (optional) and Full Audit (required) which will occur in the AWS Partner’s preferred language and location, when feasible. Every 12 months between Full Audits, AWS Partners will be assessed by AWS, using the Annual Performance- based Renewal Process detailed in the Audit Process and Timing section of this document.

AWS recommends that AWS Partners have individuals who are able to speak in-depth to the requirements at the Full Audit (remote or onsite). Best practice is for the AWS Partner to have multiple experts attending, which may include an executive sponsor, AWS practice leader, representation from HR/Finance/Marketing/Sales, one or more highly technical AWS engineers/architects, and an operations manager who is responsible for the service desk and support elements (or managed service practice manager).

AWS recently launched a calibration guide (Partner Central login required) intended for AWS Partners who are interested in applying for, or are already members of, the AWS MSP Program. This calibration guide document provides a set of guidelines against the controls (Prerequisite and Tech Validation) in the MSP Validation Checklist that is known to produce good outcomes if followed.

Program Participation and Benefits: AWS may revoke an AWS Partner’s status as an MSP Partner if, at any time, AWS determines in its sole discretion that such AWS Partner does not meet the MSP Program requirements or otherwise fails to represent the high standards expected of MSP Partners. If an AWS Partner’s status as an MSP Partner is revoked, such AWS Partner will (i) no longer receive, and will immediately cease taking advantage of, any MSP Program benefits, (ii) immediately cease use of all materials provided to it in connection with the MSP Program and (iii) immediately cease to identify itself or hold itself out as an MSP Partner.

Audit Process and Timing

Partners who join the MSP program follow a yearly Audit and Renewal Process. It is critical that Partners and their AWS teams (PDMs, PMSAs) are aware of the original award date for the MSP badge, when the partner passed their Full Audit, as this will determine the deadline for renewals going forward. The Partner’s original award date can be found in Partner Central with the following steps:

  1. Login to Partner Central
  2. At the top of the screen, hover on "Programs" then select "Program Applications"
  3. Click on the "Programs" tab
  4. Find the Managed Service Provider Program, select it, then click "View Details" to see the award date

Additionally, it is the responsibility of the Partner to ensure their Alliance Lead contact/s are up to date in Partner Central. Below is an overview of what to expect for Audit and Renewal Process:

Year 0: Full Audit
Year 1 (365 days from original award date): Performance Based Renewal
Year 2: Performance Based Renewal
Year 3: Full Audit (repeat the cycle again)

The Full Audit is an assessment of the Partner’s MSP practice against all controls, Prerequisites and Technical Validations, in the MSP Validation Checklist. Partners should begin reviewing the current Checklist (found in Partner Central) 3-6 months ahead of their renewal deadline. The auditor will contact the partner and their PDM to schedule the audit 90 days prior to the deadline. After the Full Audit occurs, the AWS Partner and AWS will receive an audit summary within 2 business days from the audit which will detail strengths, opportunities for improvement, and action items (both mandatory and recommended). A preliminary pass/fail assessment from the auditor will be provided with the audit summary. The Partner should immediately open the audit summary report and identify/begin reconciling open mandatory action items directly with AWS (no additional evidence should be sent to ISSI from this point on).

AWS Partners have 10 business days to respond to and address any identified mandatory action items with AWS directly. AWS partners should not send any additional evidence against the open mandatory action items to ISSI after the audit. All additional evidence must be sent to AWS only at aws-msp@amazon.com.

AWS has 20 business days to review the report received from ISSI, review additional evidence from the AWS partner (if any) to close mandatory action items and deliver a final pass/fail decision to the AWS Partner. Examples of KPI scenarios with open mandatory action items versus no open mandatory action items are outlined below.

Mandatory vs Recommended Action Items: Mandatory Action Items are items that must be closed out prior to approval of entry into the MSP Program. If the AWS Partner is not able to fully close a Mandatory Action Item in 10 business days, an action plan detailing how and when the item will be closed must be provided to the AWS MSP team, and the AWS MSP team will make the decision accordingly. Recommended Action Items are items that do not impact the final pass/fail assessment but are recommended as best practices by AWS. All open recommended items will be included in the final audit report and the AWS Partner may or may not address those.

Scenario 1: Open Mandatory Action Items

Action                  Responsible Parties                  Time from previous action (maximum)
Audit occurs Partner, ISSI -
Audit Summary Report submitted to AWS and the Partner                  ISSI 2 business days
Partner addresses/provides additional evidence to close
mandatory open action Items to AWS ONLY. During
this time, the auditor provides Full Audit Report to AWS for
review with open mandatory items.                  Partner, AWS, ISSI 10 business days
Additional evidence from partner reviewed, Final Audit
Report updated and AWS provides final decision on
pass/fail. Partner receives communication on decision
from AWS.                  Partner, AWS 20 business days
Total KPI: 32 business days

Scenario 2: No Open Mandatory Action Items

Action                  Responsible Parties                  Time from previous action (maximum)
Audit occurs Partner, ISSI -
Audit Summary Report submitted to AWS and the Partner                  ISSI 2 business days
Auditor provides Full Audit Report to AWS for review                  ISSI 7 business days
AWS provides final decision on pass/fail. Partner
receives communication on decision from AWS.                  Partner, AWS 20 business days
Total KPI: 29 business days

Performance-Based Renewal Process:

The MSP Program requires an annual Performance-Based Renewal process (“PBR”) to ensure high quality and consistent customer experiences. AWS MSP Partners are expected to continue to drive innovation and excellent customer experiences, as well as grow and develop their practices. The requirements of the Performance Based Renewal process include:

  • AWS Partner complies with the AWS Partner Network Terms and Conditions and remains in good standing at the tier.
  • Compliance with all current MSP Program requirements listed on the most recently released version of the program Validation Checklist.
  • Partner organization's Alliance Lead contact is up to date in Partner Central.
  • Five (5) launched opportunities through ACE tagged to 'Managed Services' in the 12 months immediately prior to the annual renewal date.

AWS reserves the right to make changes to this annual Performance-Based Renewal process at any time and will communicate the changes accordingly to the partners.

AWS will conduct an internal review of the partner's performance against the established requirements. All Performance-Based Renewals will now be addressed on a quarterly basis, based on the due date (E.g. - For renewals due by January 10, 2025, the process will be addressed by Q1 2025 which is March 31st, 2025). If you do not receive a notification from AWS regarding your Performance Based Renewal, you can consider your renewal completed and no further action is required. If you don’t meet the number of launched opportunities or tier status required for performance-based annual renewal, you will be notified to take action. Note that the Full Audit (every 3 years) does still require case studies. Please see the latest Checklist for details and requirements.

If a Partner fails to meet the performance requirements, they may, at AWS’ sole discretion, be offered a brief window of time to complete an action plan and achieve the requirements or will otherwise be immediately removed from the MSP Program.

While an audit of Checklist controls will not be reviewed during the Performance-Based Renewal process, AWS expects continued compliance to previously audited and newly released mandatory requirements and requires that AWS Partners disclose any material changes to policies, processes, and tools that impact their managed services practice as soon as those changes are made.

Full Audit (conducted every 36 months from the initial full audit):

The MSP Program also requires a Full Audit every 36 months, based on the AWS Partner’s most recent Full Audit date. This Full Audit will be conducted using the current version of the Checklist, as of the date the Full Audit is conducted. The Self-Assessment Spreadsheet (linked at the top of this page) is now a mandatory requirement for all partners ahead of their first Full Audit (when they join the program) and Full Audit renewal every three years. In order to ensure all of our partners are prepared for the audit and have the support they need, the Self-Assessment Spreadsheet should be submitted directly to aws-msp@amazon.com at least 30 days before their desired full audit date.

Partners are required to provide comprehensive responses to the Prerequisite Controls, including all relevant documentation and supporting links. For the Technical Validation controls, partners should complete the "Met" or "Not Met" evaluation only. The Technical Validation controls will then be thoroughly assessed by the auditor during the one-day audit process.

In the Self-Assessment Spreadsheet, the partners should specifically call out any areas they need direct support on from the AWS MSP team in the "Partner Response" column. From there, we will identify the right resources to assist partners in closing any gaps in meeting mandatory controls in the Checklist ahead of their audit. Even if your organization completes the Self-Assessment and does not identify any open mandatory controls, it is still required that the Self-Assessment be submitted to the MSP Program ahead of any Full Audit motion.

Impact of Merger, Acquisition and Divestiture Activity:

The MSP Program incorporates the use of an audit to validate the AWS Partner’s technical capabilities, as well as its business and delivery models. These business and delivery models are often significantly impacted in the process of mergers, acquisitions and divestitures. As a result, AWS Partners may be required to reapply and complete a new Full Audit. Please refer to the guidelines below.

  • Acquisition/Merger:

    • AWS MSP Partner acquires non-MSP Partner: No immediate action required. The MSP Partner must show any impacts to its MSP practice during its next regularly scheduled Full Audit.
    • Non-MSP Partner acquires AWS MSP Partner: New application and Full Audit required for acquiring AWS Partner to be recognized as an MSP Partner. The new business and delivery models, as well as the integration of the acquired technical capabilities, must be validated through the Full Audit process. We recommend that this be done as soon as possible to ensure continued recognition in the MSP Program.
    • AWS MSP Partner acquires another AWS MSP Partner: No immediate action required. The consolidated entity will be assessed during the next regularly scheduled Full Audit of either of the original entities (whichever date is soonest).

  • Divestiture:

    • If an AWS Partner divests a portion of its business related to its AWS MSP practice, the divesting business must immediately disclose significant impacts to its MSP practice that would materially impact its standing as an MSP Partner. Depending on the significance of the impact, the AWS Partner will either be immediately removed from
    • the MSP Program or it will be required to highlight impacts to its business during its next regularly scheduled Full Audit. The divested business will be required to apply to the MSP Program as a new AWS Partner.

Mandatory and Recommended Control Types Explained

Each control is labeled Mandatory or Recommended. During full audits, AWS Partners will be assessed against all controls in the Checklist; however, Partners only need to present detailed evidence for Mandatory controls. AWS reserves the right to introduce new Mandatory controls at any time without first introducing the new controls as Recommended controls. In most cases, net new controls can be first published as Recommended and then promoted to Mandatory in a subsequent major version release of the Validation Checklist.

Definitions

AWS Case Studies: A Case Study is a report detailing an individual customer solution and outcomes. It should include an introduction to the customer, overview of the challenge, details about the solution implemented, and outcomes realized by the customer. For the purpose of the MSP Program, all Case Studies used in the MSP application and renewals must demonstrate that the AWS Partner and customer have been under agreement to provide AWS-based managed services for a minimum of 6 months. AWS Partners may use one example per customer and may not use examples for customers who are an internal or an affiliate company of the AWS Partner. All case studies must be for projects that are in production with customers, rather than in a 'pilot' or proof of concept stage. AWS Partners are not required to use specific document format for a Case Study so long as all required information is clearly identified and included. Example Case Study templates and guides are available and may be used if desired: AWS MSP Program: Public Case Study Guide (Partner Central login required). All case studies must include the following:

  • Name of the Customer (unless the case study is anonymized, see below)
  • Customer Challenge
  • Proposed Solution
  • How AWS was used as part of the solution
  • Partner's support services during pre and post migration or implementation of the solution.
  • Existing and new solution architecture diagrams, where applicable.
  • Outcome(s)/results
  • Metrics for success
  • Start date of the engagement
  • End date of the engagement

Case studies without the above information may not be accepted by AWS. The information provided for these case studies will be used by AWS for validation purposes only.

Public Case Studies: Public case studies must be publicly available examples describing how the partner used AWS and their support services to help solve a specific customer challenge related to a managed services engagement. These publicly available examples may be in the form of formal customer case studies, white papers, videos, or blog posts. The partner will provide the publicly available URL (published by the partner) in the AWS Partner Central 'Case Study URL' field during their application process, to the external auditor during the renewal full audit, and in the performance-based renewal template during their performance based annual renewal process.

Anonymized Public Case Studies: In cases where the partner cannot publicly name customers due to the sensitive nature of the customer engagements, the partner may choose to anonymize the public case study. Anonymized public case study details will be published by AWS, but the customer name will remain private. The partner must provide the AWS Customer name in the 'Company name' field of the AWS Partner Central case study during MSP application for validation purposes, but it will not be published by AWS. During the renewal full audit and performance based annual renewal process, AWS may reach out to the partner to know the Customer name in private for validation purposes. The case study fields that will be published to Partner Solutions Finder (PSF) by AWS include the 'Title', 'Case Study Description', and 'Case Study URL'. The partner will provide the publicly available URL (published by the partner) in the AWS Partner Central 'Case Study URL' field, which must include all required elements listed above for a case study.

Launched Opportunities: AWS Partners submit opportunities through the APN Customer Engagements (ACE) platform in AWS Partner Central. Opportunities used to fulfill MSP Program requirements must include “Managed Services” as one of the selected Delivery Model options. After billing for the solution begins, AWS Partners will update the status of the opportunity to “Launched”.

AWS MSP Partner Prerequisites

The following prerequisite controls must be met and evidenced before the Technical Validation audit. Controls labeled Mandatory require detailed evidence; Recommended controls are assessed but will be promoted to Mandatory in a future major release.

Business

  • BUSP-001 - Web Presence

    Mandatory

    AWS Partner has a public landing page on their primary website that describes their AWS managed services practice and links to their public case studies. This page must describe the Partner's differentiated expertise in designing, building, and managing workloads on AWS.

    Evidence must be in the form of a public URL for their AWS MSP practice landing page.

  • BUSP-002 - Customer References & Success Stories

    Mandatory

    Partner demonstrates minimum 4 active managed services customers with documented business outcomes (e.g. cost reduction, customer revenue growth, automation rates, accuracy improvements). Two (2) of the provided case studies out of 4 case studies must have publicly available artifacts.

    These publicly available artifacts may be in the form of formal customer case studies, white papers, videos, or blog posts, while private case studies may be in the form of PDF, PowerPoint, or Word documents — none of which were used in any previous MSP audits or renewals.

  • BUSP-003 - AWS AI Competency Alignment

    Recommended

    Partner is pursuing or has achieved AWS AI Competency designation demonstrating validated technical proficiency and customer success track record.

    Partner must present evidence of AWS AI Competency designation status — either the achieved designation, or documented proof of active pursuit (e.g., application submitted, self-assessment completed, or validation scheduled)

People

  • PEOP-001 - AWS Certifications - Core

    Mandatory

    Partner maintains minimum AWS certification requirements: 3x AWS Professional or Specialty technical certified individuals, 4x Technical or Business Accredited Professionals, and 50% team-wide AWS Cloud Practitioner baseline.

    Partner must provide documented evidence of meeting the minimum AWS certification requirements: at least 3 unique individuals holding AWS Professional or Specialty technical certifications, at least 4 unique Technical or Business Accredited Professionals, and minimum 50% MSP team-wide AWS Cloud Practitioner baseline — supported by certification records.

  • PEOP-002 - AWS Certifications - AI/ML

    Mandatory

    Partner team holds minimum: 2x AWS Certified AI Practitioner, 1x AWS Certified ML Engineer Associate, 1x AWS Certified Generative AI Developer Professional

    Partner must provide documented evidence of meeting the minimum AI/ML certification requirements: at least 2 unique individuals holding AWS Certified AI Practitioner, at least 1 unique individual holding AWS Certified ML Engineer – Associate, and at least 1 unique individual holding AWS Certified Generative AI Developer – Professional — supported by certification records

Governance

  • GOVP-001 - Change Management Process

    Mandatory

    Partner operates a structured change management process (CAB or equivalent) covering infrastructure, application, and AI workload changes with risk assessment, approval workflows, and rollback procedures.

    Partner must provide documented evidence of a structured change management process (CAB or equivalent) covering infrastructure, application, and AI workload changes — including risk assessment/classification, approval workflows, and rollback procedures — supported by sample change records showing risk categorization, approvals, and (where applicable) executed rollbacks.

  • GOVP-002 - Responsible AI Policy & Framework

    Mandatory

    Partner has adopted a formal Responsible AI framework covering fairness, accuracy, transparency, accountability, privacy, and safety for all AI deployments.

    Partner must provide a documented Responsible AI framework addressing fairness, accuracy, transparency, accountability, privacy, and safety across all AI deployments — along with at least one example of an internal or external AI deployment where the framework was applied, showing how the principles were implemented and documented in practice.

  • GOVP-003 - Shared Responsibility Model

    Mandatory

    AWS Partner defines a shared responsibility model with customers for the AWS environments they manage, spanning both cloud and AI/agentic workloads. This clearly delineates which security and operational responsibilities sit with the Partner versus the Customer, and is formalized in a shared RACI matrix agreed at engagement onset.

    Partner must provide one customer-engagement-specific RACI matrix that assigns security and operational ownership between Partner and Customer across cloud and AI/agentic workloads.

Platform

  • PLATP-001 - Non-Functional Requirement

    Mandatory

    Partner delivers a detailed design document to customers for engagements that includes the approach to fulfill the non-functional requirements of the system including:

    • Definition of system requirements or goals for performance, capacity, and availability. • Service level agreements (SLAs) if applicable. • Tools and approaches used to monitor these aspects of the system in production including specific metrics. • Overview of the test or verification process for ensuring the design meets the specified requirements before it is deployed to production.

    Evidence must be in the form of implemented system detailed design documents produced within the last 18 months for 2 independent and unrelated customers with the non-functional requirements.

Security

  • SECP-001 - Encryption & Key Management

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner enforces encryption at rest and in transit for all customer data, with customer-managed key isolation, key rotation policies, and secure key management practices.

    The partner must provide proof of their AWS MSSP Competency Specialization, or alternatively, provide a security policy document that addresses encryption at rest and in transit for all customer data, customer-managed key isolation per tenant, and automated key rotation practices.

  • SECP-002 - Workload Security

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner maintains workload security standards covering their deployed compute types, including hardening baselines, runtime protection, and threat detection appropriate to each type.

    The partner must provide proof of their AWS MSSP Competency Specialization, or alternatively, provide a documented workload security standards process covering their deployed compute types (e.g., EC2, containers, serverless, AI inference endpoints), including hardening baselines applied per compute type, runtime protection mechanisms, and threat detection capabilities.

  • SECP-003 - AI Security Governance

    Recommended

    Partner classifies all AI agent deployments by level of autonomy and applies layered security controls proportional to each agent's agency — enforcing scoped identities with least-privilege access, deploying guardrails for prompt injection and data leakage prevention, continuously monitoring agent behavior for anomalies, and requiring human-in-the-loop approval gates that scale as autonomy increases across customer environments.

    Partner must provide a process document describing how AI agents are classified by autonomy level, how access is scoped per agent, how guardrails and behavioral monitoring are configured at each level, and how human approval gates are enforced for high-risk actions.

  • SECP-004 - Prompt Injection Prevention

    Mandatory

    Partner implements input validation, content filtering, and guardrails across all AI-facing endpoints to detect and prevent prompt injection attacks — ensuring user inputs are sanitized, agent scope is clearly defined, and outputs are validated before execution across customer environments.

    Partner must provide a security policy document addressing guardrail configurations for prompt attack detection, input sanitization practices, agent scope boundaries, and regular security testing procedures targeting prompt injection vulnerabilities.

  • SECP-005 - Security Incident Response

    Mandatory

    Partner has documented security incident response plan with defined playbooks for traditional and AI-specific incidents (model compromise, data poisoning, prompt injection attacks, unauthorized agent actions).

    Partner must provide an incident response plan with defined playbooks covering both traditional security incidents and AI-specific scenarios — including model compromise, data poisoning, prompt injection attacks, and unauthorized agent actions — with clear escalation paths, containment procedures, and post-incident review processes.

Operations

  • OPSP-001 - Incident Management

    Mandatory

    The Partner maintains structured incident management with defined severity levels, committed response/resolution SLAs, escalation matrices, and stakeholder communication protocols.

    Partner must provide an Incident Management process documentation defining severity levels, SLA targets, escalation paths, and communication protocols. Partners also present an example of a runbook(s) used in day-to-day operations to perform procedures for responding to specific workload/infrastructure/security alerts.

  • OPSP-002 - Service Level Management

    Mandatory

    Partner defines SLAs related to the service offerings they provide to their customers like advisory, professional services, operations services. Examples of such SLAs include but are not limited to: Service Request compliance, incident and problem management, security events, change management, deployment quality, etc.

    SLAs may include response times when customer opens ticket/initiates request, time from event or incident trigger to remediation, and turnaround time for customer-initiated changes/requests. SLAs may extend to AI service tiers including inference latency, model availability, and agent response time targets.

    Partner must provide evidence in the form of a trailing three-month SLA performance reports.

  • OPSP-003 - Toil Measurement & Reduction

    Recommended

    Partner systematically measures and reduces operational toil — defined as manual, repetitive, automatable work that scales linearly with growth (per SRE principles). Partner tracks toil as a percentage of ops time, maintains an automation backlog, and demonstrates quarterly reduction. The requirement is active measurement and a demonstrated improvement trajectory.

    Partner must provide a toil tracking report showing toil as a percentage of ops time, a prioritized automation backlog, and quarterly metrics demonstrating a downward trend.

AWS MSP Technical Validation

The following controls are assessed during the one-day Technical Validation audit. Partners indicate Met / Not Met in the Self-Assessment; the auditor validates each control during the audit.

Business

  • BUS-001 - Business Plan & AWS Strategy

    Mandatory

    Partner maintains a documented business plan with clear AWS practice strategy, including growth targets, market positioning, and investment roadmap for managed services.

    Partner must provide a documented business plan outlining their AWS managed services practice strategy, including defined growth targets (e.g., revenue, customer, or headcount goals), market positioning, competitive awareness, and target customer segments, and an investment roadmap covering planned capabilities, tooling, certifications, and hiring. The plan must demonstrate executive sponsorship and a multi-year outlook aligned to their AWS MSP practice.

  • BUS-002 - AI Transformation Roadmap

    Mandatory

    Partner has a documented AI transformation strategy showing progression from traditional MSP to AI-first delivery model, with milestones aligned with transformation plan and timeline for achieving outcomes-based service delivery.

    Partner must present a documented AI transformation strategy showing the shift from a traditional MSP to an AI-first delivery model, with defined milestones — such as adoption of AI services, % of services AI-enabled, automation coverage targets, and number of agentic use cases in production — along with measurable progress indicators, backed by executive sponsorship. The strategy must be accompanied by at least one dated, system-generated artifact evidencing progress against a milestone — for example, adoption metrics pulled from a system of record, a tooling rollout log, or minutes from a recurring review that predates the audit request.

  • BUS-003 - Financial Health & Viability

    Mandatory

    AWS Partner has processes in place for financial planning, including forecasting, budgeting, and review of financial metrics and reports. Partner demonstrates financial stability with adequate capitalization for AI investments.

    Evidence can be in any of the following forms: budgets with documented AI investment allocations, financial forecasts, financial reports for the prior quarter or year. Partner must demonstrate that AI-related investments (e.g., tooling, talent, platform development) are explicitly budgeted. Public securities filings for the most recent period are sufficient for publicly traded companies.

  • BUS-004 - Customer Value Realization Framework

    Mandatory

    Partner has a documented methodology for measuring and reporting customer business outcomes from managed services, including baseline establishment, KPI tracking, and regular business reviews with outcome data.

    Partner must present a documented methodology for measuring and reporting customer business outcomes from managed services. This should include how baselines are established, the KPIs tracked against those baselines, and the cadence of business reviews where outcome data is shared with customers. These should be supported by a sample outcome report or QBR deck demonstrating the methodology in practice.

  • BUS-005 - Go-to-Market Strategy

    Mandatory

    Partner has a defined go-to-market strategy for managed services including target verticals, use-case frameworks, competitive positioning, and sales enablement materials.

    Partner must present a defined go-to-market strategy for managed services, including identified target verticals, market size understanding, use-case frameworks, competitive positioning, and sales enablement materials (e.g., pitch decks, solution briefs, battle cards) — demonstrating a repeatable motion for taking AI-First offerings to market.

  • BUS-006 - Industry Vertical Specialization

    Recommended

    AWS Partners who currently hold ANY AWS Industry Competency specializations are exempt from this requirement.

    Partner demonstrates deep expertise in at least one specialized industry vertical, with managed services offerings tailored to that vertical's operational and business requirements.

    The partner must provide proof of their AWS Industry Competency specialization, or alternatively, provide at least one customer example demonstrating managed services delivery in a specialized industry (e.g., financial services, healthcare, manufacturing, telecom, retail, energy and utilities, media and entertainment) — including evidence of an industry-specific service offering (e.g., SOW, service description, or vertical-specific solution architecture).

People

  • PEO-001 - Organizational Structure & Staffing

    Mandatory

    Partner maintains adequate staffing levels for 24x7 managed services delivery with defined roles, responsibilities, and escalation paths.

    Partner must provide documented evidence of adequate staffing for 24x7 managed services delivery, including an org chart and staffing model showing coverage across shifts (including on-call/follow-the-sun arrangements), documented roles and responsibilities, and defined escalation paths (e.g., L1→L2→L3 and management escalation) with associated response and handoff procedures. Any subcontracted functions of the MSP practice must be clearly identified within the org chart, including the subcontractor's role, scope of responsibility, and how they integrate into the overall escalation and handoff framework.

  • PEO-002 - Cloud Center of Excellence (CCOE)

    Mandatory

    AWS Partner must maintain a Cloud Center of Excellence — a dedicated, cross-functional team responsible for creating, evangelizing, and governing standards and cloud and AI best practices across the MSP practice.

    The CCOE drives five domains:

    Cloud and AI Adoption & Retooling — Promoting cloud services and AI adoption; developing reusable tools and artifacts Training & Change Management — Coordinating cloud learning with a change-as-normal mindset Governance — Establishing processes aligned to cloud architecture frameworks, Responsible AI, and policies Strategy — Aligning cloud and AI offerings with business strategy Operations & Automation — Standardizing and automating platform components over time

    Partner must provide a documented CCOE charter, org structure, and operational processes showing how the CCOE engages across the partner's business — accompanied by at least one live artifact demonstrating ongoing CCOE activity within the last 12 months, such as meeting minutes, a documented governance cadence, or a service or offering demonstrably produced by the CCOE.

  • PEO-003 - Dedicated AI Practice Lead

    Recommended

    Partner has a designated AI Practice Lead (or equivalent) responsible for AI strategy, delivery quality, innovation pipeline, and customer outcome measurement across the AI services portfolio.

    Partner must provide documented evidence of a designated AI Practice Lead (or equivalent), including the individual's name, role definition, and documented responsibilities spanning AI strategy, delivery quality, innovation pipeline, and customer outcome measurement across the AI services portfolio — supported by an org chart or role charter showing their position and mandate within the practice.

  • PEO-004 - Forward Deployed Engineers (FDE) Team

    Recommended

    Partner has a Forward Deployed Engineering capability — dedicated technical resources embedded within customer engagements to drive hands-on implementation, operational excellence, and continuous optimization with a focus on enabling customer-facing AI and agentic AI use cases that accelerate business outcomes, revenue growth, and competitive differentiation for the customer.

    Partner must provide documented evidence of a Forward Deployed Engineering (FDE) capability — the defined role and operating model, evidence of resources embedded within customer engagements.

  • PEO-005 - Continuous Cloud and AI Learning Program

    Mandatory

    Partner has a structured continuous learning program for Cloud and AI skills. This may include formal Learning Management System or other approaches that promote a culture of continuous learning.

    Partner must provide documented evidence of a structured continuous learning program for Cloud and AI skills — such as an LMS, certification records, or training pathways — demonstrating a culture of continuous learning. Evidence should include measurable indicators of program activity and impact, such as minimum training hours per person per quarter or certification renewal rates.

  • PEO-006 - Knowledge Management & Documentation

    Mandatory

    Partner maintains comprehensive knowledge base with runbooks, playbooks, architecture decision records, and AI Agents registry accessible to all delivery team members.

    Partner must provide documented evidence of a comprehensive, centrally accessible knowledge base containing runbooks, playbooks, architecture decision records, and an AI Agents registry — demonstrating that content is maintained, version-controlled, and accessible to all delivery team members.

Governance

  • GOV-001 - Continual Service Improvement

    Mandatory

    Partner has a documented CSI program for their customers, including regular reviews, improvement initiatives tracking, and measurable outcomes demonstrating business value advancement over time.

    Partner must provide documented evidence of a Continual Service Improvement (CSI) program with their customers, including a defined review cadence, a tracked register of improvement initiatives, and measurable outcomes demonstrating business value advancement over time — supported by sample CSI reports or QBR records showing initiatives, status, and realized results.

  • GOV-002 - AI Agent and Model Governance & Lifecycle

    Recommended

    Partner implements model and agent governance covering: model and agent registry with versioning, approval gates for production promotion, explainability requirements, bias monitoring, and model/agent retirement procedures.

    Partner must provide a documented model and agent governance policy or registry demonstrating version control, production promotion approval gates, explainability standards, ongoing bias monitoring processes, and defined retirement/decommissioning procedures for models and agents.

  • GOV-003 - Data Governance for AI

    Mandatory

    Partner has data governance policies addressing the quality, lineage, and permissible scope of data that AI agents can access or act upon — covering consent management for agent data retrieval, retention policies for agent-generated and agent-consumed data, data sovereignty requirements, and governance of synthetic data if used for training or testing AI models and agents.

    Partner must provide data governance policies and supporting documentation for AI agent data access — covering data quality standards, lineage, consent management, retention, data sovereignty, and governance of synthetic data if used for training or testing — for both internal and customer-facing use cases.

  • GOV-004 - Vendor & Third-Party AI Management

    Mandatory

    Partner has governance processes for managing third-party solutions and tools like ITSM, CRM, AI Agents, AI models, and services including evaluation criteria, performance monitoring, and vendor risk assessment.

    Partner must provide a documented SOP for selecting and evaluating third-party solutions, including evaluation criteria and vendor risk assessment, and demonstrate how they monitor ongoing risks for AI-specific components such as model performance degradation, drift, and security posture. Alternatively, current industry certifications (e.g., ISO 27001, SOC2) held by the third party suppliers will be accepted as evidence.

  • GOV-005 - Risk Management Framework

    Mandatory

    Partner operates a risk management framework that includes AI-specific risks (model, data, operational, and reputational) as well as broader business risks across the AWS practice—such as financial exposure, business maturity, rapid growth, and customer concentration—with documented mitigation plans for each.

    Partner must provide a documented risk management framework that identifies and assesses both AI-specific risks (model, data, operational, reputational) and broader AWS practice business risks (financial, maturity, growth, customer concentration), along with corresponding mitigation plans for each identified risk area. Evidence must also include a live risk register with entries dated within the last 12 months, named owners and assignees, and defined response categories for each risk.

  • GOV-006 - Sustainability Best Practices

    Recommended

    Partner leverages cloud best practices and AI-driven automation to continuously optimize workload placement, resource utilization, and deployment patterns to improve energy efficiency and reduce cloud waste — including predictive scaling, AI-powered right-sizing, idle resource detection, automated data tiering, prioritization of energy-efficient instance families (e.g., Graviton), and sustainability metrics integrated into monitoring and alerting.

    Partner must provide evidence of optimization practices aimed at improving energy efficiency and reducing cloud waste — such as predictive scaling configurations, right-sizing reports, idle resource detection outputs, automated data tiering policies, Graviton adoption metrics, or sustainability dashboards with integrated monitoring and alerting.

  • GOV-007 - Agentic AI Business Impact

    Recommended

    Partner demonstrates measurable business outcomes delivered through agentic AI by either (a) transforming external customer use cases using AWS AI services, or (b) improving the partner's own internal managed service operations through AI-driven agents and autonomous workflows. Customer or internal examples must show a transition from traditional or manually-triggered approaches to an agentic AI approach deployed in an AWS-based production environment, leveraging AWS AI services .

    Evidence must include quantitative business metrics illustrating financial efficiency, operational improvement, or revenue impact — such as reduced resolution times, lower cost-to-serve, improved customer satisfaction, faster delivery cycles, or increased autonomous task completion rates.

Platform

  • PLAT-001 - Multi-Account Strategy & Landing Zone

    Mandatory

    Partner implements AWS multi-account strategy with landing zone providing account isolation, centralized governance, and standardized baseline configurations for their customer environments.

    Partner must provide a live or recorded demonstration of the partner's multi-account landing zone — walking through the OU hierarchy, SCPs, account vending process, and standardized baseline configurations applied to customer environments. The demonstration must show at least one customer environment provisioned within the last 12 months.

  • PLAT-002 - Infrastructure as Code

    Mandatory

    Partner manages customer infrastructure through code using version-controlled templates (e.g., AWS CloudFormation, CDK, Terraform, Pulumi) and enforces a consistent resource tagging strategy aligned to AWS Tagging Best Practices for cost allocation, governance, and operational visibility.

    Partner must provide live examples of version-controlled infrastructure templates and the tagging strategy (tag dictionary) with enforcement mechanisms used (e.g., AWS Tag Policies, SCPs, Resource Groups, Service Catalog). A recorded demonstration may be provided as supplementary evidence.

  • PLAT-003 - Amazon Bedrock & Foundation Model Platform

    Mandatory

    AWS Partners who currently hold the AWS AI Competency are exempt from this requirement.

    Partner demonstrates proficiency with Amazon Bedrock including: model selection and evaluation, Knowledge Bases/RAG architecture, Guardrails configuration, prompt engineering, and Model Distillation for cost optimization.

    The partner must provide proof of their AWS AI Competency specialization, or alternatively, provide one external customer example or one internal operations example demonstrating proficiency with Amazon Bedrock. Each example must show production-level usage of at least three of the following capabilities: model selection and evaluation, Knowledge Bases/RAG architecture, Guardrails configuration, prompt engineering, or Model Distillation for cost optimization. Examples should include supporting documentation (e.g., architecture diagrams, Statements of Work, deployment records, or before/after metrics) and be scoped to work delivered within the last 12 months.

  • PLAT-004 - Agentic AI Platform

    Recommended

    Partner demonstrates capability to build, deploy, and manage AI agents at scale using services like Amazon Bedrock AgentCore or third-party solutions including: Runtime, Memory, Identity, Gateway (MCP tools), and observability capabilities.

    Partner must provide one external customer example or one internal operations example demonstrating the ability to build, deploy, and manage AI agents at scale using services like Amazon Bedrock AgentCore or third-party solutions — covering at least three of: Runtime, Memory, Identity, Gateway (MCP tools), or Observability. A live or recorded demonstration of the agent platform in action is required.

  • PLAT-005 - Well-Architected

    Mandatory

    Detailed design that shows customer infrastructure is well-architected as per AWS Well-Architected Framework as outlined in https://aws.amazon.com/architecture/well-architected/ .

    Partner must provide evidence in the form of implemented system detailed design documents produced within the last 18 months for 2 independent and unrelated customers. Alternatively, if the partner has completed an AWS Well-Architected Framework Review (WAFR) for the customer examples which shows zero outstanding high-risk issues (HRIs) in the Security, Operational Excellence, and Reliability pillars, an exported WAFR report for each customer example may be presented instead.

  • PLAT-006 - AWS AI Service Expertise

    Mandatory

    AWS Partners who currently hold the AWS AI Competency are exempt from this requirement.

    Partner demonstrates deep expertise in leveraging the breadth of AWS AI and machine learning services to build, deploy, and manage their internal operations and AI workloads for customers.

    The partner must provide proof of their AWS AI Competency specialization, or alternatively, provide one example of an internal solution or customer workload designed and implemented by the partner which makes significant utilization of at least 3 AWS AI/ML services, such as:

    Amazon Bedrock Amazon Bedrock AgentCore Amazon SageMaker AI Amazon Quick Kiro AWS Transform Amazon Connect AWS Continuum/ AWS Security Agent AWS DevOps Agent AWS FinOps Agent Amazon Kendra Amazon Comprehend Amazon Textract Amazon Rekognition Amazon Transcribe

  • PLAT-007 - CI/CD & Deployment Automation

    Mandatory

    AWS Partners who hold the AWS DevOps Competency are exempt from this requirement.

    Partner operates automated CI/CD pipelines with version-controlled IaC, automated testing, defined deployment strategies (blue/green, rolling, immutable), and pipeline metrics tracking. It is recommended that partners enhance these workflows with AI capabilities such as AI-assisted code review, intelligent test prioritization, or deployment anomaly detection.

    The partner must provide proof of their AWS DevOps Competency specialization, or alternatively, provide evidence of automated CI/CD pipelines covering version-controlled IaC, automated testing, at least one defined deployment strategy (e.g., blue/green, rolling, or immutable), and pipeline metrics tracking. If AI-enhanced capabilities are implemented (e.g., AI-assisted code review, intelligent test prioritization, deployment anomaly detection), evidence of those can also be included.

Security

  • SEC-001 - Identity & Access Management

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner implements comprehensive IAM with least-privilege access, MFA enforcement, role-based access control, regular access reviews, and privileged access management across all customer environments.

    The partner must provide proof of their AWS MSSP Competency specialization, or alternatively, provide evidence in the form of a demonstration of the authentication process for accessing customer accounts and other systems including demonstration of least-privilege enforcement, MFA enforcement, regular access review cadence, and privileged access management controls.

  • SEC-002 - Cloud Security Posture Management (CSPM)

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner implements continuous, automated cloud security posture management across all customer accounts — assessing configurations against AWS best practices and industry frameworks across the expanding cloud and AI attack surface, aggregating findings from AWS security services and ISV partner solutions, and enforcing automated remediation at scale.

    The partner must provide proof of their AWS MSSP Competency specialization, or alternatively, must demonstrate a live CSPM implementation showing aggregated findings from AWS security services and relevant ISV solutions across the cloud and AI attack surface, automated compliance checks, centralized multi-account visibility, and automated remediation workflows.

  • SEC-003 - Vulnerability Management

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner operates continuous vulnerability management including automated scanning, patch management, remediation SLAs, and vulnerability tracking across infrastructure, applications, and AI components.

    The partner must provide proof of their AWS MSSP Competency specialization, or alternatively, must provide a live demonstration of their vulnerability management solution showing: continuous scanning across infrastructure, applications, containers, and AI model dependencies; patch management with defined SLAs by severity; remediation SLA compliance rates for the prior quarter; and vulnerability assessment covering AI-specific components where relevant (e.g., model serving dependencies, agent tooling).

  • SEC-004 - Cyber Recovery & Resilience

    Mandatory

    AWS Partners who hold the AWS MSSP Competency are exempt from this requirement.

    Partner implements cyber-resilient recovery capabilities — including immutable and isolated backup infrastructure, ransomware recovery playbooks with staged restoration and malware scanning, post-recovery threat hunting, and regular cyber incident simulations.

    The partner must provide proof of their AWS MSSP Competency specialization, or alternatively, must demonstrate immutable backup architecture with network-isolated recovery, ransomware recovery procedures, and evidence of a restoration task performed on production or non-production environments to test the ransomware recovery procedure — such as restoring workloads from immutable backups and validating integrity before reconnecting to production.

  • SEC-005 - Policy Management

    Mandatory

    AWS Partner has established a mechanism to evaluate and restrict permissions. This includes baselining the group and role membership of identities, evaluating the specific permissions granted to groups and roles, and evaluating AI agent action policies and tool-use permissions. This must specifically include reviews of AWS IAM policies using IAM Access Analyzer or similar tools.

    Partner must provide evidence in the form of such reviews being performed (more than once during the last 12 months) and the outcomes thereof.

  • SEC-006 - SaaS Tooling Account Access

    Mandatory

    Any third party SaaS tool or any tools administered by the AWS Partner that require access to customer AWS accounts must use IAM Roles with external IDs to provide cross-account access.

    Partner must provide evidence in the form of a list of SaaS tools with access to customer AWS accounts and example IAM role trust policies that require external ID.

  • SEC-007 - Agentic Zero Trust & Blast Radius Containment

    Recommended

    Partner enforces Zero Trust principles across all agent-to-agent interactions — verifying identity at every inter-agent communication, inspecting all traffic between agents, segmenting permissions by task scope, enforcing data isolation between agents to prevent one agent from accessing another agent's customer data, and containing the blast radius per agent so that a compromise of one agent cannot propagate to others or escalate beyond its bounded scope.

    Partner must demonstrate a scenario where multiple agents are operating across internal or customer accounts, showing: (1) an agent attempting to communicate with another agent and being authenticated before access is granted, (2) one agent being restricted from performing actions outside its assigned task scope, (3) data isolation preventing one agent from accessing another agent's customer data, and (4) a simulated compromise of a single agent where the blast radius is contained — proving the compromised agent cannot access other agents' data, tools, or customer or internal environments.

Operations

  • OPS-001 - Problem Management

    Mandatory

    Partner conducts root cause analysis, maintains known error database, implements proactive problem identification using pattern analysis and ML-driven correlation across incidents.

    The Partner must provide completed RCA reports (minimum two) with root cause findings, corrective actions, and resulting known error database (KEDB) entries. An actively maintained Known Error Database with linked incidents and workarounds must be demonstrated. For proactive problem identification, the partner must show ML-driven or pattern analysis tooling correlating recurring incidents and identifying problems.

  • OPS-002 - Observability & Telemetry Management

    Mandatory

    Partner must demonstrate methodology and tooling to deliver comprehensive observability across customer environments, including: collecting and correlating metrics, events, logs, and traces across AWS infrastructure and application layers; defining and tracking KPIs aligned to customer business needs; providing live dashboards with trend analysis and end-to-end service mapping.

    Partner must provide a live demonstration of the observability stack, example dashboards showing KPIs and telemetry signals, documentation of alert management and correlation processes, and evidence of implementation across at least one modern architecture (containers or serverless).

  • OPS-003 - AIOps & Predictive Monitoring

    Mandatory

    Partner implements AIOps capabilities beyond rule-based monitoring, including: ML-driven anomaly detection, predictive alerting before customer impact, intelligent alert correlation and noise reduction, automated capacity forecasting with proactive scaling, and automated incident remediation of known patterns through self-healing runbooks and AI-driven resolution of novel issues.

    Partner must provide a live or recorded demonstration of their AIOps platform showing ML-driven anomaly detection, predictive alerts triggered before customer impact, automation playbooks with self-healing configuration, remediation success rates, MTTR metrics, and AI-driven suggestion engine evidence.

  • OPS-004 - GenAI & Agentic AI Observability

    Recommended

    Partner must demonstrate the ability to monitor GenAI and Agentic AI workloads, including: agent session tracing, model inference performance monitoring (latency, throughput, accuracy), drift detection, audit trails of agent decisions (explainability), and cost observability for AI workloads (e.g., token consumption, inference costs per agent).

    Partner must provide a live demonstration of AI workload observability showing agent session monitoring, model/agent performance tracking with defined KPIs, drift detection or alerting mechanisms, decision audit trails for agent actions, and cost tracking (token usage or inference costs per agent).

  • OPS-005 - ITSM Platform & Service Lifecycle Management

    Mandatory

    Partner must implement an integrated ITSM platform covering: incident and problem management with ticketing, escalation, and root cause analysis; change management with approval workflows and compliance tracking; service request fulfillment with customer visibility; reporting on service performance and SLA adherence; and integration with monitoring/automation tools for auto-ticket creation and automated responses to known issues.

    Partner must demonstrate active use of the ITSM platform through a live or recorded walkthrough showing ticket workflows, change approval processes, reporting dashboards, and multiple integrations — including at least one automation driven trigger — that generate tickets or trigger remediation from cloud events.

  • OPS-006 - Chaos Engineering & Resilience Testing

    Mandatory

    Partner conducts regular resilience testing across their managed customer environments, including: fault injection experiments (e.g., AWS Fault Injection Service) to validate system behavior under failure conditions, scheduled game days to rehearse incident response with customer stakeholders, validation of backup and disaster recovery procedures against defined RTO/RPO targets, and documented findings with tracked remediation actions that feed back into runbooks and operational improvements.

    Partner must provide documentation of resilience testing methodology, examples of executed fault injection experiments or game day exercises for customer environments, evidence of DR/recovery validation against RTO/RPO objectives, and a sample findings report showing identified gaps with corresponding remediation actions taken.

  • OPS-007 - Configuration Management

    Mandatory

    Partner maintains a unified record of all configuration changes made to customer environments — including infrastructure, application, and AI/ML assets (model versions, hyperparameters, inference endpoint configurations, agent configurations). Each change must capture what was changed, when, by whom, its current status, and the associated approval workflow

    Partner must provide a demonstration of their configuration management system (CMDB or equivalent) showing a unified view of change records across infrastructure, application, and AI/ML assets — with evidence that AI model configurations (e.g., model versions, inference endpoint settings, agent parameters) are tracked alongside traditional infrastructure changes.

  • OPS-008 - Migrations & Modernization

    Mandatory

    AWS Partners who currently hold the AWS Migration and Modernization Competency designation are exempt from this requirement.

    Partner has the capability to migrate and modernize customer workloads to AWS using a standard methodology, automated tooling, and agentic AI-driven acceleration (for discovery, code analysis, transformation, and testing). The methodology must address:

    a. Portfolio discovery: Discovery tool reports and customer interviews, with a documented strategy mapped to the 7Rs, and AI-accelerated dependency mapping and wave planning. b. Governance: Stakeholder communication plan, cutover plan minimizing downtime, and test and rollback plans (including AI-assisted test generation where applicable). c. People & Skills: RACI matrix, transition plan, role-based training plans, and knowledge transfer content. d. Landing zone: AWS multi-account architecture diagrams and the tooling/process used to build and maintain it. e. Operations: Runbooks/SOPs for cloud operations, plus dashboards for events, logs, metrics, and traces. f. Security, Risk & Compliance: Documented process for gathering requirements and the tooling used to meet them. g. Application Migration/Modernization: Applications/components chosen for the pilot/MVP, lessons learned, and how AI-driven transformation improved effort, quality, or timeline.

    The partner must provide proof of their AWS Migration and Modernization Competency specialization, or alternatively, must provide evidence in the form of two or more customer examples with documentation covering the items in the control description. At least one must include refactoring or replatforming per the AWS 7Rs migration strategies, and at least one should demonstrate agentic AI tooling used to accelerate discovery, transformation, or testing — with measurable outcomes (e.g., reduced developer effort, faster timelines, improved test coverage).

  • OPS-009 - Cloud Financial Management (FinOps)

    Mandatory

    Partner delivers AI-driven cloud financial management, including: TCO analysis, cost monitoring and optimization augmented with AI/ML (anomaly detection, predictive forecasting, rightsizing, commitment planning), AI workload cost optimization (e.g., GPU rightsizing, Spot for training, inference cost tracking), and — for partners reselling AWS — tooling to show usage costs at customer-agreed rates

    Partner must provide evidence in the form of technology demonstration showing TCO analysis, cost monitoring dashboards, AI/ML-driven anomaly detection and optimization recommendations, AI workload cost optimization (e.g., GPU rightsizing, inference cost per request), and customer-rate-based usage visibility where reselling and providing managed services.

  • OPS-010 - Patch & Release Management

    Mandatory

    Partner operates structured patch and release management with automated OS, infrastructure, application patching, compliance tracking, release scheduling, and rollback capabilities for infrastructure, and applications.

    Partner must provide evidence in the form of technology demonstration showing the Patch management process, compliance reports, release calendar, and rollback procedures

  • OPS-011 - AWS Support Plan Coverage (Partner-Owned & Customer-Owned Accounts)

    Mandatory

    Partner ensures appropriate AWS Support coverage across all managed accounts. For Partner-owned accounts, all AWS Organizations management (payer) accounts and member accounts with production workloads must be enrolled when needed in a Business, Enterprise, or PLS (Partner-Led) Support subscription. For customer-owned accounts, Partner clearly communicates the value of AWS Premium Support and recommends Business or Enterprise Support for all accounts hosting production workloads; where customers opt out, Partner provides a clear explanation of the associated risks — namely, that the Partner cannot inspect and troubleshoot underlying AWS services during a production-impacting incident.

    Partner must provide a list of all AWS Organizations and managed customer accounts with their associated support levels (management and member accounts), along with evidence of communications to customers owning accounts but lack AWS Business Support coverage on production accounts.

Resources

Appendix A - Best Practice Guides and Reference Materials

Summary of Changes

VCL 8.0 is the AI-First release. It raises the bar from "can you manage cloud infrastructure?" to "can you prove AI-driven delivery at scale with measurable business outcomes?" The checklist is restructured into six sections and totals 61 controls (17 Prerequisite, 44 Technical Validation).

Summary of changes from VCL 7.1:

  • 24 net-new controls covering: agentic AI platform & agent lifecycle governance; Responsible AI framework, data governance for AI, and prompt injection prevention; agentic Zero Trust & blast-radius containment; GenAI/agentic observability (sessions, traces, drift, cost); operational toil measurement & reduction; AI transformation roadmap & industry vertical specialization; and the Forward Deployed Engineers and AI Practice Lead roles.
  • 27 updated controls — existing VCL 7.1 controls modified to incorporate AI capabilities (for example, change management now covers AI model changes; vulnerability management now covers agent dependencies; FinOps now includes AI workload cost optimization).
  • 10 retained controls — foundational controls (IAM, encryption, Well-Architected, patch management) carried forward unchanged.
  • 15 VCL 7.1 controls retired — consolidated into broader controls (for example, Role-Based Access + MFA + IAM consolidated into a single IAM control; two AWS Support Plan controls consolidated into one).

Controls by section (Total / New / Updated / Retained):

Section Total New Updated Retained
1. Business 9 5 2 2
2. People 8 3 5 0
3. Governance 10 5 5 0
4. Platform 8 3 3 2
5. Security 12 5 3 4
6. Operations 14 3 9 2
Total 61 24 27 10

Timing: VCL 8.0 has an effective pilot date of 21 August 2026 and supersedes VCL 7.1 starting 1 January 2027. VCL 7.1 remains valid for audits and renewals through 31 December 2026.