AWS MSP Partner Program Validation Checklist v5.0

AWS Managed Service Provider (MSP)
Partner Program
Validation Checklist
May 2022
Version 5.0
Va
Partner Valida
Amazon Confidential
AWS Managed Service Provider Partner Program Validation Checklist
Table of Contents
Purpose of this Document ..........................................................................................................................................3
Checklist Updates .......................................................................................................................................................3
Program Prerequisites ................................................................................................................................................3
Expectations of Parties ...............................................................................................................................................4
Audit Process and Timing ...........................................................................................................................................5
Mandatory and Recommended Requirements Explained .........................................................................................7
Definitions ..................................................................................................................................................................7
AWS Managed Service Provider Partner Program Validation Checklist ....................................................................9
1.0 Sales and Marketing ....................................................................................................................................9
2.0 Customer Success ..................................................................................................................................... 10
3.0 Business Health ......................................................................................................................................... 11
4.0 Partner Internal Systems Security ............................................................................................................ 12
5.0 Customer Obsession ................................................................................................................................. 14
6.0 AWS Skills Management ........................................................................................................................... 18
7.0 Operational Excellence ............................................................................................................................. 20
8.0 Security ..................................................................................................................................................... 24
9.0 Reliability .................................................................................................................................................. 27
10.0 Performance Efficiency ........................................................................................................................... 28
11.0 Cost Optimization ................................................................................................................................... 28
12.0 Sustainability........................................................................................................................................... 29
13.0 Advanced Capabilities ............................................................................................................................. 30
Appendix A: Best Practice Guides and Reference Materials .......................................................................... 32
Summary of Changes ............................................................................................................................................... 34
Version 5.0 Amazon Confidential page 2

Purpose of this Document

The Amazon Web Services, Inc. (AWS) Managed Service Provider (“MSP”) Partner 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 Partner Program (“MSP Program”). This Checklist provides the criteria
necessary for an AWS Partner to achieve the MSP designation and subsequently be referred to as an AWS MSP
Partner. It describes AWS’ view of the capabilities a “next generation managed service provider” should have to
support customers through all phases of the customer engagement lifecycle: plan/design, build/migrate, run,
and optimize.
AWS Partners must fill out this Checklist based on their assessment of their own capabilities. Such assessment
will serve as the basis for discussion during the Full Audit (defined below).
The goal of the MSP Program is to recognize AWS Partners that provide the best AWS Cloud managed service
experience for their customers.
Checklist Updates
This document as well as the AWS MSP program are updated regularly to account for updated best practices
and new service capabilities. To provide predictability in the update process, AWS will provide two checklist
updates per year beginning in 2022. Major updates (example 5.x), which contain new or significantly changed
controls will be published in H1 of the calendar year and will become the officially recognized version within 90
days. Minor updates (example 5.x.y), which contain clarifying language and minor updates to existing controls
will be published in Q3 of the calendar year and may be immediately used for audit. The minor version will
become the officially recognized version within 90 days of being published.
Version 5.0, published in May 2022, will become the only recognized standard for the MSP Program for any Full
Audit occurring on or after October 1, 2022. Any Full Audit in progress or completed before October 1, 2022 may
be conducted with version 5.0 or version 4.2.2 of this checklist.
Program Prerequisites
The following items must be met before scheduling the MSP Program Full Audit (defined below):
AWS Managed Service Provider Partner Program Prerequisites
AWS Service Partner Tiers Advanced or Premier tier AWS Services Partner (view requirements)
Customer Case Studies At least 4 AWS customer Case Studies, including at least 2 that are public.
AWS Solutions Provider
>90% compliance with end user reporting requirements for any AWS
Program (SPP) End User
Reporting
Partner enrolled in SPP.
Complete Checklist Self-Assessment (“Self-Assessment”) using the Checklist.
Checklist Self-Assessment The completed Self-Assessment must be mailed to [email protected],

using the following convention for the email subject line: “[AWS Partner
Name] Completed Self-Assessment.”

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.
New AWS Partners applying for the MSP Program are required to complete a
Pre-Assessment prior to scheduling a Full Audit. Upon completion of the
Checklist Self-Assessment”, the MSP Program team will review the submitted
Complete Pre-Assessment Self-Assessment and facilitate an introduction to the third- party auditing
firm, that will conduct the Pre-Assessment.
You will be contacted by the AWS MSP Program Team to schedule the Pre-
Assessment after the above prerequisites are met.
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 pre-requisites 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 “AWS
Partner Self-Assessment” column of the Checklist set forth below. The application steps in AWS Partner Central
will be the same for AWS Competency, AWS Service Delivery, AWS Service Ready or AWS MSP. For more details
on the application steps listed below or refer to the Program Guide:
Step 1: Start an Application under “View My APN Account”

Step 2: Select a Designation
Step 3: Attach an Offering
Step 4: Attach Case Studies
Step 5: Designate a Point of Contact and attach documentation
Step 6: Submit and track your application
AWS will review and respond back with any questions within 10 business days and provide information on how
to schedule a Pre-Assessment and Full Audit (as defined below).
AWS Partners who are applying for entry into the AWS MSP Program will undergo a Pre-Assessment to prepare
for the Full Audit. The Pre-Assessment is a remote session, conducted using your preferred conferencing
platform. The duration is typically 6-8 hours, and gives you the opportunity to review the audit requirements in
the current version of the AWS MSP Partner Program Validation Checklist and discuss the required evidence
with an experienced third-party MSP auditor. Upon completion of the Pre-Assessment, AWS Partners will
undergo a two-day audit of all items in the Checklist and their capabilities. AWS Partners accepted into the MSP
Program will be required to undergo a Full-Audit every 36 months thereafter. AWS Partners should prepare for
the Pre-Assessment and Full Audit by reading the Checklist, performing a self-assessment using the Checklist,
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 consents to share any information provided in objective evidence or

displayed in a demonstration. AWS will leverage an objective, third-party auditing firm to facilitate the Pre-
Assessment and Full Audit which will occur in the AWS Partner’s preferred language and location, when feasible.
Each Pre-Assessment will result in costs incurred to the Partner of a $2,000 USD fixed audit fee. Each Full Audit
will result in costs incurred to the Partner of a $3,000 USD fixed audit fee plus any related travel expenses at
their actual cost. Each engagement with the third-party auditing firm will be billed by the auditing firm and may
require a separate agreement between an AWS Partner and the auditor. 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).
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

After the Full Audit occurs, the AWS Partner should receive an audit summary (within 2 business days) from the
auditor detailing strengths, opportunities for improvement, and action items. A preliminary pass/fail assessment
from the auditor will be provided with the audit summary.
AWS Partners have 10 business days from receipt of the audit summary to respond to and address any identified
action items, which will be categorized as either Mandatory Action Items or as additional Recommended Action
Items (each defined below).
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 MSP Program Manager.
Recommended Action Items are items that do not impact the final pass/fail assessment but are recommended
by AWS. All open recommended action items will be included in the final audit report.
The auditor will submit the final audit report to AWS after the 10 business days allowed for an AWS Partner to
address Mandatory and Score-Impacting Action Items has passed, and no later than 10 business days after the
audit.
The final determination of acceptance into the MSP Program will be made within 20 days after AWS receives the
final audit report.
Annual Performance-Based Renewal Process:

The MSP Program requires an annual performance-based renewal process (“Renewal Process”) 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
Renewal Process include:
− Promotion of AWS MSP Partner AWS managed services with a public web presence: 5 Launched
Opportunities (as defined below) that include AWS managed services in the 12 months immediately prior to
the annual renewal;
− 1 public case study (as defined below) that includes AWS managed services, published in the 12 months
immediately prior to the annual renewal.
− Compliance with all current MSP Program requirements listed on the most recently released version of the
program Validation Checklist.
− AWS Partner remains in good standing at the Advanced or Premier tier, including the requirement to attain
Customer Satisfaction Responses; and
− AWS Partner complies with the AWS Partner Network Terms and Conditions.
AWS will review the AWS Partner’s performance against requirements and, if complete, will notify the Partner of
successful renewal of MSP Program status prior to the Partner’s anniversary date. 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 requirements will not be reviewed during the annual 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):

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.
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 Requirements Explained

Each requirement is labeled Mandatory or Recommended. During full audits, AWS Partners will be assessed
against all requirements in the checklist; however, Partners only need to present detailed evidence for
Mandatory requirements.
AWS reserves the right to introduce new Mandatory requirements at any time. In most cases net new
requirements will first be published as Recommended and then promoted to Mandatory in a subsequent major
version release.
Definitions
Case Study: 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 Full Audit 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. Case Studies must be
identified in writing to AWS as being either public (published by the AWS Partner and can be shared with public
audiences) or non-public (can only be shared with AWS and its third-party auditor for the purpose of the audit or
demonstrating to AWS that the AWS Partner is meeting program requirements). The AWS Partner is responsible
for clearly identifying any non-public Case Study and for gathering the necessary consents to share any Case
Study with AWS and the auditor. 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 Competency Program: Public Case Study Guide (Partner
Central login required).
Public Case Study: Publicly available customer examples must be easily discoverable from the AWS Partner’s
website, and are recommended to link to from the partners AWS MSP practice landing page required in 1.2
At least two (2) of the provided customer examples must have a publicly available customer examples describing
how the AWS Partner used AWS to help solve a specific customer challenge related to managed services. These
publicly available customer examples may be in the form of formal customer case studies, white papers, videos,
or blog posts etc.
Publicly available customer examples must be easily discoverable from the AWS Partner’s website, and are
recommended to link to from the partners AWS MSP practice landing page required in 1.2.Publicly available
customer examples must include the following:
• AWS Customer name

• AWS Partner name
• AWS Customer challenge
• How AWS was leveraged as part of the AWS Partner solution
• Outcome(s) and/or quantitative results
Note: For best practice on how to write an accepted Public Case Study see the Case Study Guide.
NOTE: the public case study requirement is not waivable, however for government customer case studies, you
make keep the customer’s name anonymous if required by the customer (eg: "A Government agency on the west
coast"). It is still required to be listed on the partners website, and mention AWS Managed Services provided.
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.”


In preparation for the Self-Assessment, Pre-Assessment and Full Audit process, AWS Partners should become familiar with the items
outlined in this document, and prepare objective evidence, including but not limited to: prepared demonstration to show capabilities,
process documentation, and/or actual customer examples. AWS Partners should ensure that they have the necessary consents to share
with the auditor all information contained within the objective evidence or any technology demonstration prior to scheduling a Pre-
Assessment or Full Audit. All evidence presented for audit must be delivered directly by the AWS Partner being audited; evidence cannot
include services delivered by third parties.
1.0 Sales and Marketing

1.1 Company AWS Partner has a company overview presentation to set the stage for customer Mandatory
Overview conversations as applicable to its MSP practice, in addition to demonstration capabilities.
Presentation will contain information about next generation cloud managed services;
how managed services are different in an AWS environment vs. traditional on premise or
hosted managed services with emphasis on automation enabled by DevOps practices.
Overview presentations contain:

• Company history
• Office locations
• Number of employees
• Location of AWS MSP support and operation staff
• Customer profile, including number, size and geography of customers, and
industry/segment
• Service differentiators
• AWS relationship overview/details, including AWS Partner Paths, monthly AWS billings,
etc.
Evidence must be a presentation delivered during the Full Audit. Presentation should be
limited to no more than 20 minutes.
1.2 Web AWS Partner has a public landing page on their primary website that describes their AWS Mandatory
Presence 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.
1.3 Sales and AWS Partner sales teams, marketing teams, and/or applicable business units supporting Mandatory
Marketing the AWS MSP practice have all completed the AWS Business Professional or AWS
Accreditations Technical Professional accreditations.
Evidence must be in the form of records of the appropriate accreditations.

2.0 Customer Success

2.1 Customer AWS Partner has ≥ 4 AWS Customer Case Studies (as defined in the Definitions section Mandatory
Case Studies above). At least two (2) of the provided case studies must have a publicly available
artifacts describing how AWS managed services delivered by the AWS Partner helped
solve a customer challenge. These publicly available artifacts may be in the form of
formal customer case studies, white papers, videos, or blog posts etc.
Publicly available customer examples must include the following:

• AWS Customer name
• AWS Partner name
• AWS Customer challenge
• How AWS was leveraged as part of the AWS Partner solution
• Outcome(s) and/or quantitative results
Note: For best practice on how to write an accepted Public Case Study see the Case
Study Guide.
Evidence can be in the form of documented References, Case Studies, whitepapers, or

internal briefings.
2.2 Customer AWS Partner has signed contracts with customers scoped to the AWS Partner’s AWS Mandatory
Contracts managed service practice. Each contract must be ongoing at the time of audit, with a
termination date in future.
Evidence must be in the form of executed customer contracts that demonstrate that the
Partner is currently providing managed services on AWS to each customer.
2.3 MSP AWS Partner is actively growing their MSP Practice on AWS. Mandatory
Practice
Growth All Customer Case Studies must be for net new customers onboarded within the last 18
months or demonstrate significant growth of an existing customer engagement. Renewal
of ongoing managed services for existing workloads is not sufficient.
Evidence must be in the form of new contracts or addenda that demonstrate customer
growth.

3.0 Business Health

3.1 Financial AWS Partner regularly assesses financial health of its business through methods such as Mandatory
Health Altman's Z-Score, Dun and Bradstreet (D&B) Paydex Score, D&B Rating, D&B Financial
Stress Score, D&B Supplier Evaluation Risk Rating, or equivalent.
AWS MSPs are trusted advisors to customers of all sizes, helping companies make
decisions based on their overall goals. Due to the importance of this role, AWS MSPs
must also show that they have viable businesses to earn and maintain customer trust.
Acceptable evidence may include D&B Company Credit Reports (or equivalent for AWS
Partner’s region) or proof that the AWS Partner is regularly assessing the financial health
of the business through internal reviews and creating plans when risks are identified.
Public securities filings for the most recent period are sufficient evidence for publicly
traded companies.
Articles in the press about the company, analyst reports, and/or statements made by the
company on their website will not be considered sufficient evidence to meet this
requirement.
Any recent or publicly announced mergers, acquisitions, or divestitures that materially

impact a company’s ability to deliver AWS managed services must be disclosed at the
time of the audit.
3.2 Financial AWS Partner has processes in place for financial planning, including forecasting, Mandatory
Planning and budgeting, and review of financial metrics and reports.
Reporting
Evidence can be in the form of either budgets, financial forecasts, and reports for the
prior quarter or month, or documented policies and processes related to financial
planning and review of financial metrics. Public securities filings for the most recent
period are sufficient evidence for publicly traded companies.
3.3 Risk and Areas of business risk including the AWS practice are outlined with documented Mandatory
Mitigation mitigation plans. This may include financial risks, age and maturity of business, planning
Plans for rapid growth, assumption or loss of large deals/customers, etc.
Evidence must be in the form of documented risk analysis and mitigation plan(s) relevant
to the AWS Partner’s AWS managed service practice.

3.4 The AWS Partner has a succession plan in place to address the loss of key leadership and Recommended
Succession engineering personnel related to its AWS MSP practice. This plan must cover at a
Planning minimum the individuals responsible for the profit and loss of the overall AWS practice,
the head of the AWS MSP practice, the technical lead for the AWS MSP practice, and any
additional personnel (e.g. engineers, operations staff, account management, etc.) with
unique knowledge or skillsets critical to continued support of customer workloads.
For each individual covered, the plan should at a minimum identify the following:
• The key functions that the individual performs in maintaining business or customer
workload operations;
• The successor who would take over each function in the event of the individual’s
departure;
• Pointers to any documentation or other resources necessary to perform each function;
and
• A record of the most recent review and/or update of the associated documentation and
resources including the date and name of the reviewer. All documentation and resources
must have been reviewed within the last 12 months.
Evidence must be in the form of a documented succession plan scoped to the AWS
Partner’s AWS MSP practice.
4.0 Partner Internal Systems Security

4.1 Security 4.1.1 AWS Partner has established security policies and procedures to protect its own Mandatory
Policies and systems from attacks and these policies have been reviewed and approved by AWS
Procedures Partner’s internal management.
Evidence of security policies and procedures may be in the form of current industry
certification related to information security (e.g., ISO 27001, SOC2) scoped to the
Partner's MSP practice or proof of infrastructure security and information management
processes and associated approvals.
4.1.2 AWS Partner has documented data classification and handling policies for Mandatory
managing their internal data. These policies define classification tiers and handling
standards for each tier.
See the AWS Data Classification whitepaper for more information and guidance on
establishing these policies.
Evidence may be in the form of current industry certification related to information

security (e.g., ISO 27001, SOC2) scoped to the Partner's MSP practice documented data
classification and handling policies.

4.2 Internal AWS Partner has reviewed all internal, Partner-owned systems that handle customer PII Mandatory
Systems for compliance with their data handling policy. This includes systems such as their
Review Customer Relationship Management (CRM) system, billing and invoicing systems, etc.
Evidence must be in the form of an inventory of all systems that handle customer PII and
documentation that each has undergone a security review and is compliant with the
appropriate data handling policy.
4.3 Security All AWS Partner employees complete annual security awareness training. Mandatory
Awareness
Training AWS Partners may use https://learnsecurity.amazon.com/ or another similar training
program.
Evidence must be in the form of training completion record for current employees.
4.4 Employee AWS Partner has defined termination processes and checklists for off-boarding of Mandatory
Offboarding personnel relevant to the AWS Partner’s AWS managed service practice in order to
ensure all access to customer and Partner systems and data is revoked.
Evidence must be in the form of completed off-boarding records scoped to the AWS
Partner’s AWS managed service practice; examples must include termination of
personnel access to AWS Partner and customer systems. Records may also be in the
form of current industry certification related to information security (e.g., ISO 27001,
SOC2) that are scoped to include the AWS Partner’s AWS MSP practice.
4.5 Service The AWS Partner defines and tests processes to respond to events that could impact Mandatory
Continuity their ability to service customers. These procedures cover complete data and
infrastructure loss, environmental events that affect significant portions of the workforce
(e.g., disasters that prevent physical access to corporate offices), and interruptions in
third party services critical to servicing customers (e.g., a prolonged outage to the
internal ticketing and helpdesk systems). Business continuity tests that exercise
alternative/backup infrastructure, tools, and capacity should be conducted annually.
Evidence must be in the form of process documentation that addresses the above, as
well as results of a business continuity test performed within the last 12 months.
Alternatively, ISO 22301 certification specifically scoped to the AWS Partner’s AWS MSP
practice is also sufficient.
4.6 Supplier 4.6.1 AWS Partner has defined processes for selection and evaluation of suppliers (e.g., Mandatory
Management SaaS vendors or any other third parties to whom activities or services are
subcontracted).
Evidence must be in the form of records of supplier selection and evaluation. Evidence
of proper supplier management procedures may also be in the form of current industry
certification related to information security (e.g., ISO 27001, SOC2).

4.6.2 Where AWS Partner uses SaaS solutions for systems that contain customer Mandatory
information or have access to AWS resources, AWS Partner must show that due diligence
has been carried out to assess the security compliance of these solutions with a focus on
customer privacy and security.
Evidence must be in the form of records of supplier selection and evaluation. As

evidence of assessment of security compliance, AWS Partner must show overview of the
following: SaaS providers’ security documentation, authentication and authorization
validation, MFA capabilities, availability characteristics, data backup plan, and disaster
recovery plan.
4.7 Internal AWS Partner defines a standard set of security controls implemented for all internally Mandatory
AWS Account owned AWS accounts. This standard at a minimum includes all items defined in Appendix
Security A: Minimum AWS Account Security Configuration.
Evidence must be in the form of security dashboards showing the security configuration
status of the partners' AWS accounts. All high or critical severity findings must be
accompanied with documentation on how the risk is being mitigated and/or timelines
for remediation.
5.0 Customer Obsession

5.1 Customer 5.1.1 AWS Partner has a mechanism to objectively capture customer satisfaction data. Mandatory
Satisfaction This is done via formal survey process, contact-based surveys after a customer
interaction, or as part of customer review meetings. The purpose is to ensure AWS MSP
partners have recurring feedback mechanisms in place which allow them to measure the
success of their customer engagements.
Evidence must be in the form of a demonstration of how feedback is collected. AWS

owned and operated Customer Satisfaction (CSAT) data collected through Partner
Central will not be accepted, as this information cannot be shared with partners without
customers explicitly granting permission.
5.1.2 AWS Partner has defined an acceptable score threshold and has a documented Mandatory
process for following up on low-scores and customer dissatisfaction, and documents the
resolution.
Evidence must be in the form of a low-score follow up process, and a customer example
showing where this process was used.
5.2 Service AWS Partner defines SLAs related to response times, actions, and notifications by AWS Mandatory
SLAs Partner to its customers.
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.
Evidence must be in the form of SLA documentation and supporting processes and
metrics scoped to the AWS Partner’s AWS managed service practice.

5.3 Customer AWS Partner has regular customer review meetings to discuss the performance of its Mandatory
Review services/SLAs and to share reports with the customer. The purpose is to ensure
customers understand the value of a managed solution; particularly since proactive
services that work well may appear unnecessary to an end customer.
Evidence must be in the form of documentation from a customer review meeting (may
be the same example used above), complete with recommendations and reports
provided to customer.
5.4 SLA and AWS Partner takes actions to continually improve performance to objectives. Evidence of Mandatory
Service continual improvement includes records of actions taken to improve performance,
Performance particularly when established objectives are not being met.
Optimization
Evidence must be in the form of explanation and any examples where improvements
were identified and implemented within the last 12 months scoped to the AWS Partner’s
AWS managed service practice.
5.5 Data 5.5.1 Customer contracts define the specific legal ownership of data, including Mandatory
Ownership arrangements for handling of customer data upon termination of the contract by either
and Customer party, including:
Offboarding • Time commitment as to when data/account is handed to customer
• Format and method for transfer of data/account credentials
• If applicable, the process for removal of non-customer IAM accounts, groups, roles,
and federation
Evidence must be in the form of a contract template scoped to the AWS Partner’s AWS
managed service practice addressing the above requirements.
5.5.2 AWS accounts are not shared across multiple customers. This does not apply in Mandatory
cases where the AWS Partner operates a multi-tenant software product they own in a
software as a service (SaaS) model. Third party software products managed by the
Partner on AWS on behalf of the customer must be deployed to dedicated accounts per
customer.
Evidence must be in the form of a documented policy that describes how customer
environment isolation is maintained including procedures for creating new AWS
accounts or assuming management of existing customer accounts.
5.5.3 AWS Partner has a defined procedure for offboarding customer AWS accounts from Mandatory
the Partner’s managed services that enables the customer to retain ownership of their
data and AWS accounts. For partners who are a member of the Solution Provider
Program (SPP), the procedure must cover the process for executing a Consent to
Assignment with AWS in order to transfer ownership and root account credentials of all
accounts (including the organization management account) to the customer. See
https://partnercentral.awspartner.com/ContentFolderPartner?id=0690h000007sZADAA2
for more details.
Evidence must be in the form of a documented customer offboarding procedure.

5.5.4 AWS Partner defines and agrees upon transition plans with all customers in the Recommended
event their services are discontinued. These plans should ensure a smooth handover of
operational, security, and governance processes and ensure customers have adequate
time and support to migrate off proprietary tools and services provided by the Partner.
Evidence must be in the form of an example transition plan agreed upon by an existing
customer.
5.6 AWS 5.6.1 AWS Partner has enrolled all AWS Organization management accounts (aka payer Mandatory
Support Plan accounts) in a Business or Enterprise AWS Support plan.
Evidence must be in the form of a list of AWS Organizations managed by AWS Partner
and each organization's management account’s support level.
5.6.2 AWS Partner clearly communicates to customers the value of AWS Premium Mandatory
Support plans and recommends Business or Enterprise support for all customer accounts
hosting production workloads. Customers who opt out of AWS Support are provided
with a clear explanation of the associated risks, i.e., that the AWS Partner does not have
access to inspect and troubleshoot underlying AWS services in the event of a production
impacting incident.
Evidence must be in the form of a list of managed customer accounts with associated
AWS support levels and communications to customers without AWS Business Support
coverage on production accounts.
5.7 Customer AWS Partner provides 24x7 customer service available over multiple communication Mandatory
Service means; may be a staffed 24x7 call center or 8x5 service with after-hours support (e.g.,
Availability pager/alert support after-hours on a rotational basis).
AWS Partner must explain or show how customer service is provided; if AWS Partner
does not maintain a staffed call center on a 24-hour basis, there must be documented
procedures for after hours, weekend, and holiday support.
Evidence must be in the form of a documented agreement (formal or otherwise) with

customer covering this requirement.
5.8 Service 5.8.1 Support priority and severity levels are defined, documented, and conveyed to Mandatory
Desk customers.
Operations
AWS Partner must provide documentation defining support priority and severity levels,
and must explain or show how this information is communicated to customers.
5.8.2 AWS Partner defines foundational SLAs related to response times, actions, and Mandatory
notifications to its customers.
Evidence must be in the form of SLA documentation and supporting processes and
metrics scoped to the AWS Partner’s AWS managed service practice.

5.9 Ticketing AWS Partner has an ITSM ticketing system capable of the following: Mandatory
System
5.9.1 Event/Incident ticket creation and escalation. Mandatory
AWS Partner must show how event/incident tickets are created and escalated.
5.9.2 Immediate logging and time stamping of tickets. Mandatory
AWS Partner must provide evidence of immediate logging and time stamping of tickets.
5.9.3 Documented escalation process for escalating to AWS Support, including flowchart Recommended
of process, timeframes for escalating to AWS, definition of the types of cases that get
escalated with defined criteria, and closed loop process to ensure smooth handoff and
ticket resolution.
AWS Partner must provide a documented escalation process addressing the above
requirements.
5.9.4 Escalation process provides automated escalation alerts. Mandatory
AWS Partner must demonstrate how automated escalations occur.
5.9.5 Updates from AWS on AWS Support cases are automatically ingested into the Recommended
ticketing system. This is done to ensure updates or requests for more information from
AWS are not missed by AWS Partner operations staff. Standard ticket routing and
escalation rules must be in place to ensure updates on AWS Support cases are actioned
in a timely fashion.
Sending updates from the partner’s ticketing system to AWS Support Center is not
required.
Valid methods of integration include ingestion of AWS Support emails into the AWS
Partner’s ticketing system or direct integration with the AWS Support API.
Evidence should be in the form of a technology demonstration showing how support

case updates are ingested into the ticketing system including examples of tickets with
associated support case information.
5.9.6 Verification by customer that the case has been closed satisfactorily. Mandatory
AWS Partner must provide evidence of customer verification of case closure, e.g., by
providing examples of closed cases that have been customer approved.
5.10 AWS- AWS Partner tracks cases escalated to AWS Support, and provides regular reviews with Recommended
Specific their own team to share lessons learned, leveraging information obtained from those
Support meetings for improving AWS Partner’s internal knowledge base.
Metrics
Evidence must be in the form of a demonstration of the tracking system and examples of
knowledge base entries.

5.11 AWS Partner provides web accessible customer reports. Reports should allow customers Recommended
Customer to self-select parameters such as devices and thresholds. Examples of reports provided
Reports are:
• Incident management
• Non-service affecting incidents
• Performance analysis
• Assets/resources
• Exceptions
Evidence must be in the form of a demonstration of customer accessible web portal or

other repository.
5.12 AWS Partner provides customers with workload or solution-specific SLAs (e.g., Recommended
Workload or application uptime, response times or latency, batch processing success rates, etc.).
Solution-
Specific SLAs Evidence must be in the form of SLA documentation, metrics demonstrating SLA
compliance, and a description of the technical architecture and processes used to meet
the SLA.
6.0 AWS Skills Management

6.1 Cloud AWS Partner maintains a Cloud Center of Excellence (CCOE). Mandatory
Center of
Excellence A CCOE is a team of people dedicated to creating, evangelizing, and institutionalizing
(CCOE) best practices, frameworks, and governance for evolving technology operations. This
team becomes a central force through which the organization can evolve the way that it
serves customers in this space.
It is critical for a next-generation managed service provider to build and maintain a CCOE
to enable leveraging of best practices across the organization and across the breadth of
their offered services.
Evidence of a CCOE must be in the form of documented charter, organization structure,

and operational process for the CCOE and how it engages across the AWS Partner’s
business.
6.2 Personnel 6.2.1 AWS Partner manages personnel capacity related to their AWS MSP practice. Mandatory
Skills and
Capacity Evidence must be in the form of resource planning processes detailing how AWS Partner
Management ensures that appropriate resources are available to meet business demand, scoped to
the AWS Partner’s AWS managed service practice. This may include, for example,
ensuring that there are sufficient AWS Certified Solutions Architecture Professionals
available based on the number of customers.

6.2.2 AWS Partner has defined processes and checklists for onboarding of personnel Mandatory
relevant to the AWS Partner’s AWS managed service practice.
Evidence must be in the form of completed on-boarding records scoped to the AWS
Partner’s AWS managed service practice; examples may include completed checklists,
training plans, or other records.
6.2.3 AWS Partner has a defined strategy for continuously improving the technical Recommended
expertise of their staff. This may include formal training and certification and/or other
approaches that promote a culture of continuous learning.
Evidence must be in the form of examples of learning events or activities conducted

within the past 12 months.
6.3 Solution The AWS Partner delivers a detailed design document to customers for major Mandatory
Capabilities engagements. This document must be reviewed and approved by an AWS expert from
AWS Partner who holds a current AWS Solutions Architect certification.
Evidence must be in the form of implemented system detailed design documents

produced within the last 18 months for 3 independent and unrelated customers. Each
document must contain the following components:
6.3.1 Documentation of customer requirements. Mandatory
6.3.2 Architectural details of the proposed design. Mandatory
6.3.3 Approach to fulfill the non-functional requirements of the system including: Mandatory
• 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.
The overall architecture defined in the design document must align to these
requirements.
These elements must be defined in the original design document and not just recorded
after the system has been deployed.
6.3.4 Assessment of customer’s security requirements and procedures with gap Recommended
identification.
6.3.5 Detailed design that shows customer infrastructure is well-architected as per AWS Mandatory
Well-Architected Framework.

6.3.6 Evidence that an employee who held a current AWS Solution Architect certification Mandatory
reviewed and approved the design, and provided the final deliverable.
This evidence demonstrates that the policy covered in 6.4 was followed for each
example design document.
6.4 Expert The AWS Partner has a documented policy requiring an AWS Solutions Architect – Mandatory
Design Associate or Professional certified individual to review the design and implementation of
Review all customer AWS projects. The policy must also include specific guidance for when
reviews should be conducted by individuals with Professional or Specialty level
certifications.
Evidence must be in the form of a documented policy.
7.0 Operational Excellence

7.1 AWS Partner evaluates the operational readiness of processes, procedures, and Recommended
Operational personnel to support customer workloads before deploying to production. Partner uses a
Readiness consistent process (including manual or automated checklists) to determine when
customer workloads are ready to go live.
Evidence must be in the form of documented processes including checklists to determine

operational readiness.
7.2 Flow of Evidence for each of the following sub-items must be in the form of a customer example Mandatory
Changes into demonstrating the end-to-end process for validating and managing changes to
Production production.
7.2.1 AWS Partner uses version control to manage code and deployment assets. Mandatory
7.2.2 AWS Partner has standard procedures for testing and validating changes in non- Mandatory
production environments before deploying to production.
7.2.3 AWS Partner has a system for managing approvals of changes before being Mandatory
deployed to production.
7.2.4 For AWS resources owned and deployed by the AWS Partner, the Partner uses Mandatory
either declarative (e.g., AWS CloudFormation or HashiCorp Terraform) or imperative
(e.g., AWS Cloud Development Kit) automated infrastructure deployment tools.

7.3 The AWS Partner maintains records of environment configuration changes. There must Mandatory
Configuration be a system that enables operators to list all changes made to the environment by the
Management Partner and track the following details about each change:
• Resources that were added/removed/updated
• Date and time of the change
• Current status (e.g. deployed/rolled back)
• Individual who executed the change
• Approval workflow or alert of change
This can be implemented using a Configuration Management Database (CMDB) or a
combination of other tools such as code repositories, infrastructure as code services,
automated deployment pipelines, and issue tracking or workflow systems. If multiple
tools are used, there must be a single unified view that provides all of the details listed
above.
Evidence must be in the form of a customer example with demonstration of the ability to
view configuration records and identification of recent approved configuration changes
for that customer environment.
7.4 7.4.1 Changes can be rolled back in the event of a failed deployment. Mandatory
Deployment
Risk Evidence must be in the form of a runbook or automation for rollback with log of
Mitigation historical examples of failed deployments in last 12 months.
7.4.2 AWS Partner has capabilities to automate the rollback of changes based on Recommended
automated testing of production environments.
Evidence must be in the form of an example rollback automation process with log of
historical examples of rollback in last 12 months.
7.4.3 AWS Partner has capabilities for implementing limited/canary deployments, Recommended
parallel environment deployments (e.g., blue/green deployments, traffic shifting), or
other advanced approaches for limiting the risk of failed production changes.
Evidence must be in the form of a customer example demonstrating one of the above
deployment approaches.
7.5 Patch 7.5.1 AWS Partner has automated the process of patching customer compute resources. Mandatory
Management
Evidence must be in the form of a technology demonstration of the patch automation
tooling in use.
7.5.2 AWS Partner has defined processes for testing backwards compatibility with Mandatory
applications before applying patches in production.
Evidence must be in the form of a documented process and example test results.
7.5.3 AWS Partner has reporting on the patch status of customer compute resources. Mandatory
Evidence must be in the form of a demonstration of patch status reporting.

7.6 Customer AWS Partners who hold the AWS DevOps Competency are exempt from this requirement. Mandatory
Deployment
Pipelines AWS Partner supports automated deployments by customers. Customers must be able
to deploy new versions of applications to managed compute resources without manual
involvement from AWS Partner. Manual approval steps are acceptable.
Evidence must be in the form a demonstration of an automated deployment in a

sandbox environment as well as an example customer with automated deployments
configured for a production environment. AWS Partner must show build/pipeline
execution history or other deployment logs showing consistent usage of automated
deployments by the customer.
7.7 Standard 7.7.1 AWS Partner defines a standard approach to maintain the health of all customer Mandatory
Workload workloads.
Health and
Event Evidence must be in the form of a documented standard for implementing basic
Response workload monitoring that covers all of the following.
Evidence for each of the following sub-items must be in the form of a demonstration of
the implemented standard in a customer environment.
7.7.2 AWS Partner defines standard operational metrics for the AWS services they Mandatory
support.
7.7.3 AWS Partner collects operational metrics for all customer workloads using a tool Mandatory
such as Amazon CloudWatch. This tool must provide operators with the ability to view
real-time metrics dashboards and visualize historical trends.
7.7.4 AWS Partner has a standard approach for establishing metrics baselines and Mandatory
defining alerts that indicate workloads are at risk.
7.7.5 Standard alerts create items in the AWS Partner's ticketing/ITSM system. Mandatory
Evidence must include examples of tickets created from alerts.
7.7.6 AWS Partner has standard runbooks or Procedures for responding to specific alerts. Mandatory
7.7.7 AWS Partner has automated responses to standard alerts/events. Recommended
7.8 Critical 7.8.1 AWS Partner has capabilities to provide extensive operational planning, advanced Mandatory
Workload monitoring, and event response for critical customer workloads. These capabilities are
Health and not required to be deployed for every customer workload, but must be available for
Event customers who need it.
Response
Evidence must be in the form of two customer examples that demonstrate all other
items in this control.
7.8.2 AWS Partner works with customers to define key performance indicators based on Mandatory
desired business outcomes (e.g., order rate, customer retention rate, and profit versus
operating expense) and customer outcomes (e.g., customer satisfaction) for their critical
workloads.
7.8.3 AWS Partner works with customer to build mechanisms to capture metrics that Mandatory
measure achievement of defined KPIs (e.g., HTTP response codes on order URL).

7.8.4 AWS Partner defines workload metrics to measure the health of the workload and Mandatory
underlying infrastructure (e.g., interface response time, error rate, requests made,
requests completed, and utilization).
7.8.5 AWS Partner collects and aggregates the defined workload metrics in a centralized Mandatory
system.
7.8.6 AWS Partner collects and aggregates workload logs into a centralized system and Mandatory
generates metrics from this log data.
7.8.7 AWS Partner implements statistical or machine learning anomaly detection models Mandatory
(typically using existing ISV/open source tools or AWS CloudWatch anomaly detection) to
generate alerts across a broad range of workload metrics including infrastructure and
application layers. Anomaly detection is used to reduce false positives in alerts and avoid
alarm fatigue in operations staff.
7.8.8 AWS Partner has implemented predictive models (typically using existing ISV/open Recommended
source tools) that can identify trends in monitoring and logging data and alert or trigger
actions before an anomaly or threshold breach is detected.
7.8.9 Alerts create items in the AWS Partners ticketing/ITSM system. Mandatory
Evidence must include examples of tickets created from alerts.
7.8.10 AWS Partner has documented runbooks or Procedures for addressing specific Mandatory
alerts.
7.9 Incident 7.9.1 AWS Partner has documented incident management processes, including: Mandatory
Response • How incidents are identified
• How incidents are logged
• How incidents are categorized
• How incidents are prioritized
• How incidents are investigated and diagnosed
• How incidents are resolved
• How incidents are closed
An incident is an unplanned interruption to an IT service or reduction in the quality of an
IT service. Failure of a configuration item that has not yet affected service is also an
incident – for example, failure of one disk from a mirror set. Incident management is the
process responsible for managing the lifecycle of all incidents. Incident management
ensures that normal service operation is restored as quickly as possible and the business
impact is minimized.
AWS Partner must provide evidence of a documented incident management process that
addresses the above requirements; an example must be provided. Alternatively,
evidence may be in the form of current industry certification related to ITSM (e.g., ISO
20000) scoped to the AWS Partner’s AWS managed service practice.
7.9.2 AWS Partner has a defined process for pushing information to customers regarding Mandatory
the status of ongoing incidents based on predefined SLAs, business impact, and/or
incident severity.
Evidence must be in the form of process documentation and example customer

communications from a recent incident.

7.10 Resource AWS Partner has a strategy for tracking and managing the AWS resources across Mandatory
Management customer workloads and environments. They have capabilities to logically group
resources using resource tags and report on those resource groups.
Evidence must be in the form of a technology demonstration.
7.11 Resource AWS Partner provides reporting to customers that maps business services and functions Recommended
and Service to the underlying AWS resources and other infrastructure components.
Mapping
7.12 7.12.1 AWS Partner has established processes for continuous improvement that includes Mandatory
Operations a regular cadence for reviewing operational processes, identifying opportunities, and
Improvement prioritizing efforts.
7.12.2 AWS Partner performs post-incident analysis and provides communication to Mandatory
customers after customer-impacting events. The analysis process should identify
contributing causes and define an action plan to develop mitigations and limit or prevent
recurrence. Tailored communications regarding the contributing causes and action plan
are shared with customers in a timely fashion.
Evidence must be in the form of an example of a completed post-incident analysis

including completed action plan and customer communications.
7.12.3 AWS Partner maintains a knowledge management system for organizing Mandatory
information about internal operational processes and customer workload-specific
details. This includes processes for identifying new content to be created, and existing
content that should be updated or archived.
Evidence must be in the form of a demonstration of the knowledge management system.
8.0 Security
8.1 AWS AWS Partner defines a standard set of security controls implemented for all managed Mandatory
Account customer environments. This standard at a minimum includes all items defined in
Configuration Appendix A: Minimum AWS Account Security Configuration.
Evidence must be in the form of security dashboards showing the security configuration
status across all AWS accounts in at least one AWS Organization managed by the AWS
Partner. All high or critical severity findings must be accompanied with documentation
on how the risk is being mitigated and/or timelines for remediation.
8.2 Identity 8.2.1 AWS Partner has a documented identity and access management strategy for Mandatory
and Access handling authentication and access to customer resources including AWS accounts,
Management servers, databases, etc.
Evidence must be in the form of a technology demonstration, and a process

documentation that addresses the above, and one customer example scoped to the AWS
Partner’s AWS managed service practice.

8.2.2 AWS Partner uses a centralized identity provider for managing access to all AWS Mandatory
accounts and other systems containing customer data.
Evidence must be in the form of a demonstration of the authentication process for

accessing customer accounts and other systems.
8.2.3 AWS Partner assigns permissions based on functional roles and follows the Mandatory
principle of least privilege.
Evidence must be in the form of example functional roles and the mechanisms used to
map identities and permissions to those roles.
8.2.4 AWS Partner has established a mechanism to evaluate and restrict permissions. Mandatory
This includes baselining the group and role membership of identities and evaluating the
specific permissions granted to groups and roles. This must specifically include reviews of
AWS IAM policies using IAM Access Analyzer or similar tools.
Evidence must be in the form of such reviews being performed (more than once during
the last 12 months) and the outcomes thereof.
8.2.5 AWS Partners ensures that all access to AWS accounts by human or machine Mandatory
identities owned by the Partner uses temporary credentials. Cases where specific AWS
services require the use of static credentials (e.g., Amazon SES SMTP credentials) are
allowed as long as the policies for each IAM user are limited to the service in question.
Evidence must be in the form of a listing of IAM roles that support Partner access
scenarios.
8.2.6 3rd party SaaS tools, or services operated by the AWS Partner that allow self- Mandatory
service registration by customers require external IDs in conjunction with IAM roles to
provide cross-account access.
Evidence must be 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.
8.2.7 All access to AWS accounts by human identities from the AWS Partner requires Mandatory
multi-factor authentication (MFA).
Evidence must be in the form of a demonstration of the mechanism used to enforce MFA
within the identity provided used for AWS access.
8.2.8 AWS Partner configures sign-in systems that manage access to customer resources Mandatory
to enforce minimum password length.
8.2.9 Day to day operations are executed using limited permissions. Operators assume Mandatory
more privileged access only when necessary. Root account credentials are never used
unless absolutely necessary.
Evidence must be in the form of a demonstration of limited and privileged roles and the
mechanism used for escalating privileges.

8.2.10 Access to customer accounts is logged. Recommended
Evidence must be in the form of logs showing such access occurred during last 12
months and how these were communicated to the customer (as mutually agreed
between AWS partner and Customer).
8.3 Public AWS Partner has tooling and processes to prevent and/or detect configurations that make Recommended
Resources customer resources unintentionally or unnecessarily publicly accessible. This should cover
at minimum the following resources:
Amazon S3 buckets
Amazon RDS instances
Amazon EC2 instances
Security groups with unrestricted access to sensitive ports
Amazon EBS snapshots
Amazon RDS snapshots
Amazon Machine Images (AMIs)
Evidence must be in the form of a technology demonstration of the implemented controls

and reporting demonstrating compliance of managed customer accounts.
8.4 For items with a severity score of "medium" or higher, AWS Partner applies security Recommended
Dependency patches or deploys alternative mitigations within 30 days.
Patching
Evidence must be in the form of recent logs demonstrating patches were applied in a
timely fashion.
8.5 Security AWS Partner maintains a system for reporting, prioritizing, and tracking known security Recommended
Issue issues in customer environments. This system must include mechanisms for customers
Reporting and and internal resources to report security concerns, as well as processes for tracking
Mitigation threat information feeds such as the Common Vulnerabilities and Exposures (CVE) list.
Evidence must be in the form of a demonstration of the Partner's internal security issue
tracking system. This may be the same as the ITSM system demonstrated in 5.9.
8.6 Incident 8.6.1 AWS Partner maintains response plans in the form of playbooks for likely security Recommended
Response incidents.
Evidence must be in the form of example incident response plans.

8.6.2 AWS Partner runs periodic game days or security incident simulations to exercise Recommended
their defined response plans.
Evidence must be in the form of documentation of security game days conducted within
the past 12 months.

8.7 Security 8.7.1 AWS Partner defines security event logging requirements including retention Mandatory
Event Logging periods with customers.
Evidence must be in the form of a customer example of agreed upon requirements.
8.7.2 AWS Partner captures required security events and implements controls to ensure Mandatory
retention periods are honored.
Evidence must be in the form of a customer example demonstrating logs are captured
and retained for the agreed upon periods.
8.8 Shared AWS Partner defines security requirements, responsibilities, and expectations for Mandatory
Responsibility customers related to the AWS environments managed by the Partner.
Model
Evidence must be in the form of onboarding documentation provided to customers.
8.9 Access AWS Trusted Advisor checks popular code repositories for access keys that have been Mandatory
Key Exposure exposed to the public and for irregular Amazon Elastic Compute Cloud (Amazon EC2)
Detection usage that could be the result of a compromised access key. If an access key exposure is
detected the service triggers an event in AWS CloudWatch Events. It is critical that AWS
MSP Partners actively monitor these events and create mechanisms to ensure they are
responded to quickly.
The AWS Partner must implement an automated mechanism for handling all AWS Health
events with service type “RISK” in all managed customer accounts. At a minimum, an
automated system must be in place to create new tickets in an ITSM or security ticketing
system at the highest severity when exposed access key notifications are received. See
https://partnercentral.awspartner.com/apex/WebcastMain?Id=a1G0h00000CXSz3EAH
for an example solution.
Additionally, the Partner must have a documented procedure for handling exposed
credential notifications that includes deleting or rotating the exposed credentials.
Evidence must be in the form of a technology demonstration and documented response

procedure.
8.10 SaaS Any tools administered by the AWS Partner that require access to customer AWS Mandatory
Tooling accounts must use IAM Roles with external IDs to provide cross-account access.
Account
Access
9.0 Reliability
9.1 Backups 9.1.1 AWS Partner implements automated backups for all customer workloads. Mandatory
Evidence must be in the form of example backup jobs for Amazon RDS, Amazon EBS,
Amazon S3, and Amazon DynamoDB.

9.1.2 AWS Partner performs periodic data recovery to verify the integrity of backups and Mandatory
processes. Recovery tests are evaluated against each workload's predefined recovery
time objective (RTO) and recovery point objective (RPO).
Evidence must be in the form of records of recovery tests performed within the last 12
months.
9.2 Disaster 9.2.1 AWS Partner defines Recovery Time Objectives (RTO) and Recovery Point Recommended
Recovery Objectives (RPO) for workloads with customers.
Evidence must be in the form of example documentation (e.g., contracts, disaster

recovery plans, etc.) shared with the customer for a customer workload.
9.2.2 AWS Partner implements recovery strategies to meet the defined objectives and Recommended
conducts periodic tests to ensure RPO and RTO are met.
Evidence must be in the form of documentation of disaster recovery tests completed

within the past 12 months.
10.0 Performance Efficiency

10.1 AWS Partner provides advanced performance monitoring for key customer workloads. Recommended
Performance
Monitoring
10.2 AWS Partner helps customers improve the performance of their workloads by Recommended
Performance implementing changes in architecture, services, and/or configuration to achieve
Optimization predefined targets.
Evidence must be in the form of a customer example including specific performance

improvement targets, optimization approach, and outcomes.
11.0 Cost Optimization

11.1 AWS AWS Partner provides customers with tooling (e.g., AWS Cost Explorer and AWS Budgets Mandatory
Cost or equivalent products) to understand their AWS costs.
Reporting
11.2 Cost AWS Partner assists customers in defining cost attribution categories and implementing Recommended
attribution appropriate tagging schemas.

11.3 Cost 11.3.1 AWS Partner regularly assess customer AWS costs and provides recommendations Mandatory
Optimization for optimization.
Evidence must be in the form of documented recommendations provided to a customer.
11.3.2 AWS Partner has implemented multiple cost optimization strategies for Recommended
customers.
Evidence must be in the form customer examples for two of the following cost
optimization strategies that resulted in an AWS cost reduction of at least 20% for the
workload:
* Commitment discounts (e.g. AWS Savings Plans, or Reserved Instances)

* Resource right-sizing and storage tier/type optimization
* Amazon EC2 Spot Instances
* Regional migration
* Data transfer optimization
* System re-architecture or migration to lower-cost services
Examples should include a brief description of the cost modelling and analysis completed
and actual before and after costs for the workload.
12.0 Sustainability
12.1 AWS Partner is committed with a sustainability vision as part of their long-term strategy. Recommended
Sustainability
Commitment Evidence must be in the form of a policy documentation / communication with a
leadership commitment from a CxO office.
12.2 AWS Partner has identified and implemented an improvement process geared towards Recommended
Improvement the sustainability journey including steps such as: Identifying targets, evaluating,
processes prioritize and plan, test and validate, deploy and measure sustainability benefits.
12.3 AWS Partner is aware of / has experimented with fine-tuning non-functional Recommended
Sustainability requirements towards achieving better sustainability outcomes for customer whilst
as a non- maintaining. Example of such tweaks could be adjusting quality of result, response
functional times, availability etc.
requirement

12.4 AWS Partner takes steps towards optimizing workload placement, architecture for user, Recommended
Sustainability software, data, hardware and deployment patterns to increase energy efficiency.
best practices Example of such optimizations could include optimization steps taken based on user
behavior, architecture design, data patterns, hardware patterns etc.
13.0 Advanced Capabilities

13.1 AWS Partners who currently hold the AWS Migration Competency designation are Mandatory
Migrations exempt from this requirement.
AWS Partner has capabilities for migrating customer workloads from on-premises or
other cloud environments to AWS using a standard methodology that addresses the
following:
* Resource discovery
* Migration pattern identification (e.g., rehost, replatform, refactor, etc.)
* Landing zone design and deployment
* Cut over planning
* Application testing
* Rollback planning
Evidence must be in the form of two customer examples with the associated migration
plans covering the items above. At least one example must include refactoring or
replaforming as described in https://aws.amazon.com/blogs/enterprise-strategy/6-
strategies-for-migrating-applications-to-the-cloud/

13.2 AWS AWS Partners who currently hold three or more AWS Competency or AWS Service Mandatory
Service Delivery designations are exempt from this requirement.
Expertise
AWS Partner has demonstrated expertise in leveraging the breadth of AWS services to
improve or implement solutions for customers.
Evidence must be in the form of four example customer workloads designed or

rearchitected by the AWS Partner which each make significant utilization of at least three
AWS services beyond the following:
Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Virtual Private Cloud (Amazon VPC)
Amazon Relational Database Service (Amazon RDS)
Amazon Simple Storage Service (Amazon S3)
Amazon Elastic Block Storage (Amazon EBS)
AWS Identity and Access Management (IAM)
Amazon CloudWatch
AWS CloudTrail
AWS CloudFormation

Appendix A: Minimum AWS Account Security Configuration
New Account Creation

Account Creation Process Document a process for creating new AWS accounts that ensures the following best
practices are implemented.
(Recommended) Automate the account creation process and configuration of guardrails.
Account Contacts Configure all primary and alternate account contacts

Use email distribution lists for all account contacts
Use phone numbers owned and controlled by the AWS Partner or customer, not
employee’s personal phone numbers for all account contacts.
Root User Security Ensure the root user is only used for tasks that require it.
For AWS Organizations management accounts, standalone accounts, or any accounts
where you do not deny root access using a service control policy (SCP), set a strong
password for the root user and enable MFA. Store the password securely.
Ensure no access keys exist for the root user.
(Recommended) Deny access from the root user in AWS Organization member accounts
using a service control policy (SCP).
Event Logging Create a multi-region trail in AWS CloudTrail.
Send CloudTrail logs to an Amazon Simple Storage Service (Amazon S3) bucket in a
separate security or audit account.
Enable log file server-side (SSE-KMS) encryption.
Enable log file validation.
Secure the S3 bucket where CloudTrail logs are stored. Ensure the bucket policy does not
provide unnecessary access. Enable MFA delete. Enable server-side encryption.
Cloud Security Posture Management
Security Standard Adopt a security standard such as the AWS Foundational Security Best Practices or the
CIS AWS Foundations Benchmark and configure tooling to continuously evaluate your
compliance with that standard (e.g. AWS Security Hub).
The standard you adopt should at minimum validate the following:
MFA is enabled for the root user.
No access keys exist for the root user.
CloudTrail is enabled in all regions or a multi-region trail exists.
Public access to S3 buckets is disabled
Security groups do not allow unrestricted access to high risk ports.
Posture Monitoring Aggregate findings across logical groups of accounts (e.g. per customer organization).
Create alarms with notifications for new high-severity risks identified.
Document exceptions for any risks classified as critical or high severity with planned
remediation dates.

Appendix B: Best Practice Guides and Reference Materials
Always check the whitepapers URL for the latest versions
Amazon Web Services Whitepapers:

http://aws.amazon.com/whitepapers/
AWS Security Center:

http://aws.amazon.com/security/
AWS Security Best Practices:

https://aws.amazon.com/whitepapers/aws-security-best-practices/
AWS Compliance:
https://aws.amazon.com/compliance/
AWS Cloud Audit Academy:

https://www.aws.training/Details/eLearning?id=41556
Introduction to AWS Security Credentials:

http://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
Getting Started: Amazon Identity and Access Management:

http://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html
IAM Best Practices:

http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
Making Secure Requests to Amazon Web Services:

http://aws.amazon.com/articles/1928?_encoding=UTF8&andjiveRedirect=1
Building Fault Tolerant Applications on AWS:

http://d36cz9buwru1tt.cloudfront.net/AWS_Building_Fault_Tolerant_Applications.pdf
AWS Well-Architected:
https://aws.amazon.com/architecture/well-architected/
https://wa.aws.amazon.com/wat.pillar.security.en.html
https://wa.aws.amazon.com/wat.question.SEC_9.en.html
6 Strategies for Migrating Applications to the Cloud blog:

https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
AWS Competency Case Study Guide: (Partner Central Login Required)

https://partnercentral.awspartner.com/ContentFolderPartner?id=0690h000005YqTsAAK

Summary of Changes
Scoring has been removed and replaced with Mandatory and Recommended requirements.
Version 5.0 introduces a new section structure aligned to the AWS Well-Architected Framework pillars. Many requirements
have changed numbers and/or sections, some requirements have been removed, and some have been added. Please
review the change log sheet in the Self Scoring Worksheet for a detailed mapping of all changes between version 4.2.2 to
version 5.0.

AWS MSP Partner Program Validation Checklist v5.0

Uploaded by

Copyright:

Available Formats

AWS MSP Partner Program Validation Checklist v5.0

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AWS MSP Partner Program Validation Checklist v5.0

Uploaded by

Copyright:

Available Formats

AWS Managed Service Provider (MSP)

Version 5.0 Amazon Confidential page 2

Purpose of this Document

Complete Checklist Self-Assessment (“Self-Assessment”) using the Checklist.

Checklist Self-Assessment The completed Self-Assessment must be mailed to [email protected],

Version 5.0 Amazon Confidential page 3

Step 1: Start an Application under “View My APN Account”

Version 5.0 Amazon Confidential page 4

Audit Process and Timing

Annual Performance-Based Renewal Process:

Version 5.0 Amazon Confidential page 5

Full Audit (conducted every 36 months):

Impact of Merger, Acquisition and Divestiture Activity:

Version 5.0 Amazon Confidential page 6

Mandatory and Recommended Requirements Explained

Version 5.0 Amazon Confidential page 7

Version 5.0 Amazon Confidential page 8

AWS Managed Service Provider Partner Program Validation Checklist

1.0 Sales and Marketing

Overview presentations contain:

Evidence must be in the form of records of the appropriate accreditations.

Version 5.0 Amazon Confidential page 9

2.0 Customer Success

Publicly available customer examples must include the following:

Evidence can be in the form of documented References, Case Studies, whitepapers, or

Version 5.0 Amazon Confidential page 10

3.0 Business Health

Any recent or publicly announced mergers, acquisitions, or divestitures that materially

Version 5.0 Amazon Confidential page 11

4.0 Partner Internal Systems Security

Evidence may be in the form of current industry certification related to information

Version 5.0 Amazon Confidential page 12

Version 5.0 Amazon Confidential page 13

Evidence must be in the form of records of supplier selection and evaluation. As

5.0 Customer Obsession

Evidence must be in the form of a demonstration of how feedback is collected. AWS

Version 5.0 Amazon Confidential page 14

Evidence must be in the form of a documented customer offboarding procedure.

Version 5.0 Amazon Confidential page 15

Evidence must be in the form of a documented agreement (formal or otherwise) with

Version 5.0 Amazon Confidential page 16

5.9.2 Immediate logging and time stamping of tickets. Mandatory

AWS Partner must demonstrate how automated escalations occur.

Evidence should be in the form of a technology demonstration showing how support

Version 5.0 Amazon Confidential page 17

Evidence must be in the form of a demonstration of customer accessible web portal or

6.0 AWS Skills Management

Evidence of a CCOE must be in the form of documented charter, organization structure,

Version 5.0 Amazon Confidential page 18

Evidence must be in the form of examples of learning events or activities conducted

Evidence must be in the form of implemented system detailed design documents

• Definition of system requirements or goals for performance, capacity, and availability.

Version 5.0 Amazon Confidential page 19

Evidence must be in the form of a documented policy.

7.0 Operational Excellence

Evidence must be in the form of documented processes including checklists to determine

Version 5.0 Amazon Confidential page 20

Evidence must be in the form of a demonstration of patch status reporting.

Version 5.0 Amazon Confidential page 21