Evidence and audits

Microsoft applies the Microsoft Supplier Data Protection Requirements (DPR) to its suppliers through their contracts and through Supplier Security and Privacy Assurance (SSPA). The DPR is a set of contractual requirements, not a law: see How to think about supplier requirements. The SSPA procedures on this page come from the SSPA Program Guide Version 12, March 2026, which is the current Program Guide. The DPR evidence on this page comes from DPR Version 10, October 2024, which is the edition that MFF-8 and OFF-8 adapt. For the differences between the editions, see DPR Version 10 and Version 12.

Before work starts

The SSPA Program Guide Version 12 gives this rule for newly enrolled suppliers (page 16): "Newly enrolled suppliers must complete issued requirements to secure a SSPA Status of Green (compliant) before engagements can begin." The Microsoft Procurement SSPA page gives the same rule: "for new suppliers, work cannot start until this is complete."

Microsoft also checks the approvals in the Data Processing Profile of the supplier. The Program Guide gives these two rules (page 3):

• "Microsoft purchasing tools validate the SSPA Status is Green (for each supplier in scope for SSPA) and requisite approvals prior to allowing an engagement to move forward."
• "Microsoft business groups will only be able to create engagements with suppliers where the data processing activity matches the approvals the supplier obtained."

The Data Processing Profile of the supplier controls which DPR requirements Microsoft issues and which assurance applies. For the profile selections and the enrollment scope, see Data Processing Profile.

SSPA uses different assurance documents, for example the four below. Each document has a different author and different conditions:

Document	Who signs, writes, or submits it	Conditions
Self-attestation to the DPR	The Authorized Representative of the supplier signs and submits it.	Each enrolled supplier submits it each year. See Annual self-attestation.
Letter of Attestation	An independent assessor writes it.	The letter is unqualified. All non-compliant issues are resolved before the letter goes to SSPA. See Prepare for independent assessment.
ISO certification (ISO 27001, ISO 27701, or ISO 42001)	The supplier submits it.	SSPA applies the profile, section, and contract conditions for each certification. See Certification.
SOC 2 report	The supplier submits it.	SSPA can accept it for DPR Section J only, and only with security trust criteria and no qualifications. See Certification.

A self-attestation is not independent assurance. For a profile with independent assurance, the supplier gives the self-attestation and one of the independent assurance alternatives.

Annual self-attestation

The SSPA Program Guide Version 12 gives this rule for all enrolled suppliers (pages 15 and 16): "All suppliers enrolled in SSPA must complete a self-attestation of compliance to the DPR within 90 days of receiving the request." DPR Version 10 gives the same annual cycle (Supplier Response, page 3): "Suppliers confirm compliance to these requirements annually using an online service administered by Microsoft."

These conditions apply to the self-attestation:

• "request" — The "request" comes each year. The Program Guide adds that it can come more frequently "if the Data Processing Profile is updated mid-year".
• Clock — The 90 days start when the supplier receives the "request".
• No extension — "The SSPA team is not authorized to provide extensions for this task."
• Late self-attestation — "Supplier accounts will change to an SSPA Status of Red (non-compliant) if the 90-day period is exceeded. New in-scope purchase orders cannot be processed until the SSPA Status turns to Green (compliant)."
• Profile change — After a change to the Data Processing Profile, new tasks are issued. If the supplier does not complete them "within the 90-day time frame allowed", the SSPA Status turns to Red, and "the account is at risk of being deactivated from Microsoft Accounts Payable systems" (page 3).

The Authorized Representative completes the self-attestation. DPR Version 10 defines the Authorized Representative as "a person that has the appropriate level of authority to sign on behalf of the company" (Glossary, page 27). The definition adds: "This person would have the requisite privacy and security knowledge or have consulted a subject matter expert prior to submitting their response to an SSPA Program action." Program Guide Version 12 gives this recommendation (page 16): "Authorized representatives that will complete the self-attestation should ensure they have sufficient information from subject matter experts to reply to each requirement with confidence." The Program Guide adds that "by adding their name to a SSPA form they are certifying that they have read and understand the DPR". The Program Guide gives the Authorized Representative three tasks (page 16):

1. "Determine which requirements apply."
2. "Post a response to each applicable requirement."
3. "Sign and submit the attestation in the Microsoft Supplier Compliance Portal."

The Program Guide also tells suppliers that "A separate security contact is required to sign off on Section J of the DPR specifically". The security contact "may be called upon to assist should a security incident occur involving your company".

The supplier can mark an issued requirement as "does not apply", "local legal conflict", or "contractual conflict". The SSPA team examines these selections. For the conditions of each selection, see Data Processing Profile and Contracts and data.

Independent assessments

The SSPA Program Guide Version 12 gives four causes for independent assurance. These are the Data Processing Profile, the Subprocessor role, AI Systems, and a decision by SSPA. Independent assurance does not replace the annual self-attestation.

Data Processing Profile. The profile table of the Program Guide shows which profiles have "Independent Assurance of compliance" as a requirement, and the alternatives for each profile. See Certification.

Subprocessor role. Microsoft decides the Subprocessor role: in the profile table, the role "is determined by Microsoft". The Program Guide adds (page 11): "Suppliers cannot self-identify as a Subprocessor at Microsoft because it requires pre-approval by internal Privacy teams." It also tells suppliers: "Suppliers that are on a published Microsoft Subprocessor list will also be asked to provide independent verification of compliance." For a supplier with this role, the Program Guide gives this rule (page 16): "the supplier cannot change this approval and will be required to have an Independent Assessment conducted annually."

The profile table gives independent assurance alternatives for the Subprocessor role (profile 8). See Certification for the alternatives and their conditions.

For the difference between a Subprocessor and a Subcontractor, see Subcontractors and Subprocessors.

AI Systems. The Program Guide tells suppliers: "All suppliers providing AI Systems will be required to provide Independent Assurance options" (page 13). The profile table gives assurance alternatives for DPR Section K: see Certification.

The profile table applies the Section K row to "Any of the profiles above and Artificial Intelligence (AI) Systems". As a result, the Section K alternatives do not replace the alternatives for the profile. For the Publisher and Deployer selections, see Data Processing Profile.

Decision by SSPA. The Program Guide gives this rule (page 17): "If circumstances beyond standard triggers warrant additional due diligence, SSPA may require an independent assessment regardless of the Data Processing Profile." The Program Guide gives these examples:

• "a request from division privacy or security"
• "validation of data incident remediation"
• "an SSPA team out of cycle review"
• "requirement for automated data subject rights execution"

The Program Guide also tells suppliers that "SSPA may ask for collaborating evidence of compliance for a particular Data Protection Requirement to support compliant attestations" (page 16). Suppliers "may be selected to provide evidence as described in the Microsoft Supplier Data Protection Requirements outside of the annual compliance cycle". This "will only apply to companies that do not receive the Independent Assessment task".

Certification

The SSPA Program Guide Version 12 gives certification alternatives in its Data Processing Profile Table (pages 4 to 7). The independent assurance alternatives in this table apply only where the supplier meets the full profile conditions. SOC 2, HITRUST, and the Version 10 Section J substitution have their own conditions below. For profiles 1, 2, 6, and 7, the profile rows give only self-attestation. The rows for Payment Cards, SaaS, and AI Systems can apply together with each profile.

Profile	Selections in the profile table	Independent assurance alternatives
3	Scope: Confidential. Processing Location: At Supplier. Processing Role: N/A. Highly Confidential Data: YES. Payment Cards, SaaS, Use of Subcontractors, Website Hosting, and Healthcare: N/A.	An independent assessment against the DPR, or ISO 27001.
4	Scope: Confidential. Processing Location: At Supplier. Processing Role: N/A. Highly Confidential Data: N/A or YES. Payment Cards: N/A. SaaS: YES, or Use of Subcontractors: YES, or Website Hosting: YES. Healthcare: N/A.	An independent assessment against the DPR, or ISO 27001.
5	Scope: Personal & Confidential. Processing Location: At Supplier. Processing Role: Processor. Highly Confidential Data: YES. Payment Cards, SaaS, Use of Subcontractors, Website Hosting, and Healthcare: N/A.	An independent assessment against the DPR, or an independent assessment against Sections A to I with ISO 27001, or ISO 27701 with ISO 27001.
8	Scope: Personal & Confidential. Processing Location: "Any". Processing Role: Subprocessor, which Microsoft decides. Highly Confidential Data: N/A or YES. Payment Cards, SaaS, Use of Subcontractors, Website Hosting, and Healthcare: N/A.	The same three alternatives as profile 5.
9	Scope: Personal & Confidential. Processing Location: At Supplier. Processing Role: Processor. Highly Confidential Data: N/A or YES. Payment Cards: N/A. Subcontractors: YES, or SaaS: YES, or Website Hosting: YES, or Healthcare: YES.	The same three alternatives as profile 5, or a HITRUST report "only for a covered entity or healthcare service provider in the US".
One of the profiles above, with Payment Cards	The requirements of the profile, and Payment Card Industry assurance.	A PCI DSS certification.
One of the profiles above, with SaaS	The requirements of the profile, and the ISO 27001 certification that the contract gives for the functional services.	An ISO 27001 certification that applies to the services that the supplier gives.
One of the profiles above, with AI Systems	Self-attestation that includes DPR Section K, and independent assurance against Section K.	An independent assessment against Section K, or ISO 42001.

The Program Guide identifies the standards that SSPA relies on for close mapping to the DPR (page 17): "The ISO 27701 (privacy), ISO 27001 (security), and ISO 42001 for AI Systems (DPR Section K) are relied on as providing close mapping to the DPR." Each profile in the table has the self-attestation as a requirement. As a result, no certification removes the annual self-attestation.

These conditions also apply:

• SOC 2 — "A SOC 2 report with security trust criteria may be accepted for DPR Section J (security) where no qualifications are noted" (page 17). SSPA decides if it accepts the report. The Program Guide gives this alternative for Section J only.
• HITRUST — "Where Supplier is a covered entity under HIPAA or healthcare service provider in the United States, we will accept a HITRUST report for privacy and security coverage" (page 17).
• ISO 27001 in DPR Version 10 — The Section J Evidence of Compliance column of DPR Version 10 gives this rule: "A valid ISO 27001 Certification is an acceptable substitute for Section J: Security. Contact SSPA to apply this substitution." It adds: "You will need to provide the certification" (page 13). This substitution applies to Section J only.
• SaaS — On page 12, the Program Guide gives this rule: "Suppliers that meet the SaaS definition included on the Data Processing Profile will be required to provide a valid ISO 27001 certification or other certification that applies to the software service(s) as noted in your contract with Microsoft." Page 18 uses "may be required" and makes ISO 27001 conditional on the Microsoft Cloud Services Agreement: "Suppliers that meet the SaaS definition included on the Data Processing Profile may be required to provide a valid ISO 27001 certification if this is required in the Microsoft Cloud Services Agreement." The certificate covers the software services in the Microsoft contract. The Program Guide adds: "Please do not submit a datacenter certification." SSPA reviewers "will validate that your submission meets the contract obligation" (page 18).
• Payment cards — A supplier that handles payment card information for Microsoft gives evidence that it adheres to PCI DSS. The volume of transactions decides if a Qualified Security Assessor certifies compliance or if the supplier completes a self-assessment questionnaire. The Program Guide adds: "Suppliers who process or store Microsoft customer payment data must possess a current PCI Tier 1 certification as a service provider" (pages 11 and 12).

Prepare for independent assessment

The SSPA Program Guide Version 12 gives the conditions for an independent assessment (page 17). The supplier selects the assessor. The assessor writes the Letter of Attestation. The Program Guide gives these conditions:

• Assessor — The supplier selects an assessor "with sufficient technical training and subject knowledge to adequately assess compliance".
• Qualification — The assessor has one of these qualifications:
  • The assessor has an affiliation with the International Federation of Accountants (IFAC) or the American Institute of Certified Public Accountants (AICPA).
  • The assessor is "a certified ISO auditor qualified for ISO 27001, ISO 27701, and ISO 42001 where applicable".
  • The assessor has certifications "from other relevant privacy and security organizations", for example IAPP or ISACA.
• DPR edition — "The assessor must use the most current DPR which includes the evidence required to support each requirement." This edition can come after DPR Version 10, which MFF-8 and OFF-8 adapt. See DPR Version 10 and Version 12.
• Responses — The supplier gives the assessor "their most recently approved DPR attestation responses".
• Scope — The assessment includes "all in-scope data processing activity executed against the supplier account number which received the request".
• More than one account — If one assessment includes more than one supplier account, the letter names these accounts.
• Letter — The assessor writes an unqualified Letter of Attestation on "the approved advisory letter template".
• Remediation and submission — "all non-compliant issues must be resolved and remediated before the confirmation letter is submitted to the Microsoft Supplier Compliance Portal for SSPA team review."
• Content of the letter — "The letter submitted to SSPA must not include any statements where the supplier cannot meet the Data Protection Requirements as written."

Modulos recommends that the supplier assemble the submission documents and record the date and version of each document. A Modulos export does not replace the self-attestation, the Letter of Attestation, or the check by the SSPA team. For the export functions in Modulos, see Reports and exports.

DPR evidence

Each section of the DPR has a requirement column and an Evidence of Compliance column. The Evidence of Compliance column gives the evidence for each requirement. For the structure of the DPR, see How to think about supplier requirements. Items 3, 4, 39, 46, and 47 are about the personnel and the assets that Performance uses.

DPR Version 10, Section A, has two items about personnel (pages 4 and 5):

• Item 3, accountability — "Assign responsibility and accountability for compliance with the DPR to a designated person or group within the company." The Evidence of Compliance column tells the supplier to name the role of that person or group. It also gives "A document describing the authority and accountability of this person or group that demonstrates a privacy and/or security role".
• Item 4, training — "Establish, maintain, and perform annual privacy and security training for anyone (system administrators, operations staff, management, third parties, etc.) that will have access to Microsoft Personal or Confidential Data." Item 4 adds: "Supplier personnel may be required to complete additional trainings provided by Microsoft divisions."

The Evidence of Compliance column for item 4 gives these records and contents:

• "Annual records of attendance are available and can be provided to Microsoft upon request."
• Training content that is "regularly updated" and includes privacy and security principles, for example safeguarding passwords and log-in monitoring.
• Evidence of training on privacy regulatory requirements, security obligations, and contract obligations.
• For IT staff: "training for incident response and simulated events and automated mechanisms to facilitate effective response to crisis situations".
• If the Microsoft Personal Data includes PHI: HIPAA training, security reminders, log-in monitoring, safeguarding passwords, and the uses and disclosures that the Business Associate Agreement permits.

Use the evidence that the Evidence of Compliance column of DPR Version 10 gives for each item.

Subcontractor evidence

DPR Version 10, Section G, applies "If the supplier intends to use a subcontractor to Process Microsoft Personal or Confidential Data" (pages 10 and 11). A Subcontractor gets obligations from the supplier. A Subprocessor is a different actor that Microsoft engages. See Subcontractors and Subprocessors.

Item	Requirement column	Evidence of Compliance column
25	"Notify Microsoft prior to subcontracting services or making any changes concerning the addition or replacement of subcontractors." Item 25 adds: "Indicate your acceptance of this obligation even if you do not currently engage subcontractors but may in the future."	"Validate that Microsoft Personal and/or Confidential Data is Processed only by companies known to Microsoft as required in the applicable contract" or "captured in the SSPA database". "Supplier may post their subcontractor list online and include a link to the page in the SSPA database."
26	"Document the nature and extent of Microsoft Personal and Confidential Data sub-Processed by subcontractors, ensuring that the information collected is required to Perform."	"Supplier maintains documentation concerning the Microsoft Personal and Confidential Data disclosed or transferred to subcontractors."
27	"Where Microsoft is a Controller of Microsoft Personal Data, ensure the subcontractor uses Microsoft Personal Data in accordance with a Data Subject's stated contact preferences."	"Demonstrate how a Microsoft Data Subject preference is utilized by subcontractors." Supporting documentation "that includes the timeframe for a subcontractor to honor a preference change".
28	"Limit the subcontractor's Processing of Microsoft Personal or Confidential Data to those purposes necessary to fulfill the supplier's contract with Microsoft." If the data is PHI, the supplier also makes a Business Associate Agreement with the Subcontractor. That agreement limits the Processing by the Subcontractor and protects the data "in the same manner as the Business Associate Agreement between Microsoft and Supplier".	Documentation that Performance needs the data, and the Business Associate Agreement "if applicable".
29	"Review complaints for indications of any unauthorized or Unlawful Processing of Microsoft Personal Data."	"Supplier can demonstrate systems and processes are in place to address complaints concerning unauthorized use or disclosure of Microsoft Personal Data by a subcontractor."
30	"Notify Microsoft promptly upon learning that a subcontractor has Processed Microsoft Personal or Confidential Data for any purpose other than those related to Performance."	"Supplier has provided the instruction and means for a subcontractor to report the misuse of Microsoft data."
31	"If the supplier collects Personal Data from third parties on behalf of Microsoft, the supplier must validate that the third-party data protection policies and practices are consistent with the supplier's contract with Microsoft and the DPR."	"Supplier can provide documentation of due diligence performed regarding the third party's data protection policies and practices."
32	"Promptly take actions to mitigate any actual or potential harm caused by a subcontractor's unauthorized or Unlawful Processing of Microsoft Personal and Confidential Data."	"Supplier must maintain documentary evidence of plan and procedure and furnish evidence of documentation to Microsoft upon request."

For items 26 and 28 to 31, the Evidence of Compliance column adds: "Supplier will furnish documentary evidence to Microsoft upon request".

The SSPA Program Guide Version 12 adds a current disclosure rule (page 13):

Suppliers using subcontractors who will Process Personal and or Microsoft Confidential Data must disclose those subcontractors. Additionally, the supplier must also disclose the countries where that personal data will be processed by each subcontractor.

DPR Version 11 adds a requirement for written terms with Subcontractors: see DPR Version 10 and Version 12.

Security evidence

DPR Version 10, Section J, starts with this requirement (page 13):

The supplier must establish, implement, and maintain an information security program that includes policies and procedures, to protect and keep secure Microsoft Personal and Confidential Data in accordance with good industry practice and as required by Law.

If the Microsoft Personal Data is PHI, the supplier also performs "a periodic technical and non-technical evaluation in response to environmental and operational changes affecting the security of PHI". The "evaluation" establishes "the extent to which the supplier's policies and procedures meet the requirements of the HIPAA Security Rule". For the ISO 27001 substitution for Section J, see Certification.

Item	Requirement column	Evidence of Compliance column
37	"Perform annual security assessments that include" the risks and vulnerabilities to Microsoft Personal Data, the measures to decrease the risks, "reviewing of major changes to the environment", and "maintaining change logs".	"Supplier has documented security assessments, change logs and scan results." "The required change logs must track changes, provide information regarding the reason for the change, and include the name and title of the designated approver." "Records for past 90 days available upon request."
39	"All physical and virtual assets used to support Performance, security, and operations must be accounted for and have an identified owner." The supplier is accountable for "maintaining an inventory of these information assets, establishing acceptable and authorized use of the assets, and providing the appropriate level of protection for the assets throughout their life cycle". The item does not limit these assets to the assets that only the Microsoft work uses.	An inventory with the location of each device, the "data classification of the data on the asset", the "record of asset recovery upon termination of employment or business agreement", and the "record of disposal of data storage media". The Evidence of Compliance column adds: "all physical and virtual devices used by Supplier personnel with @microsoft.com credentials to access Microsoft data must be fully managed solely by Microsoft, with no additional security software installed beyond what Microsoft has provisioned."
40	"Establish and maintain access rights management procedures to prevent unauthorized access to any Microsoft Personal or Confidential Data under supplier control."	An access rights management plan, for example lockout, automatic logoff, Multi-Factor Authentication, and "deactivation of user accounts (including accounts used by employees or subcontractors) on employment or termination within 48 hours". A procedure to examine user access, "enforcing the principle of least privilege".
41	"Define and implement patch management procedures that prioritize security patches for systems used to Process Microsoft Personal or Confidential Data." Item 41 tells the supplier to "conduct vulnerability scans on a monthly basis with high level compliance report showing monthly scans for the prior 12 months".	Documented severity definitions, a "Documented procedure to implement emergency patches", and "Patch management records which track approvals and exceptions and includes patching compliance data. Records for past 90 days available upon request."
46	"The supplier must ensure that backup planning processes protect Microsoft Personal and Confidential Data from unauthorized use, access, disclosure, alteration, and destruction."	"documented response and recovery procedures", and "procedures to periodically back up, securely store (physically, and via use of data encryption), and effectively recover critical data".
47	"Establish and test business continuity and disaster recovery plans."	A disaster recovery plan with criteria for "critical" systems and the names of these systems. For each of these systems, a procedure "that ensures an engineer who does not know the system could recover the application in under 72 hours". "Annual (or more frequent) testing and review of disaster recovery plans to ensure recovery objectives can be met."

Section J also has items 38, 42 to 45, and 48 to 52. These items are about mobile devices, anti-virus and anti-malware software, "security-by-design principles", data loss prevention, and "secrets" in software. They are also about identity and Multi-Factor Authentication, encryption of data in transit, disk encryption, encryption "at rest", and anonymized data in development and test environments. Read these items in DPR Version 10. Subsequent DPR editions add more security items: see DPR Version 10 and Version 12.

Data Incidents

DPR Version 10 defines a Data Incident (Key Definitions, page 2):

"Data Incident" means (1) a breach of security leading to the accidental or Unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Microsoft Personal Data or Microsoft Confidential Data transmitted, stored or otherwise Processed by Supplier or its Subcontractors, or (2) security vulnerability related to Supplier's handling of Microsoft Personal Data or Microsoft Confidential Data or confidentiality incident as defined under Bill 64 (2021, chapter 25).

DPR Version 10, Section I, item 34, gives the notice duty (page 12):

Supplier has an incident response plan that requires Supplier to notify Microsoft per contractual requirements, as described by applicable privacy law, or without undue delay, whichever is sooner, upon becoming aware of a Data Incident.

The clock starts "upon becoming aware of a Data Incident". The supplier notifies Microsoft at the earliest of three times: the time in the contract, the time in the applicable privacy law, or "without undue delay". Item 34 gives no fixed number of hours or days. Item 34 also tells the supplier to cooperate with Microsoft:

Supplier must at Microsoft's request or direction, cooperate with Microsoft in any investigation, mitigation, or remediation of the Incident, including providing Microsoft with an incident summary, information detailing the compromise, a scope of data accessed, and mitigations used. Access to Supplier personnel or hardware needed to conduct a forensic review may also be necessary.

The Evidence of Compliance column of item 34 gives an incident response plan with a step to notify Microsoft. Section I has two more items:

• Item 35 — "Implement a remediation plan and monitor the resolution of each Data Incident to ensure that appropriate corrective action is taken on a timely basis." The evidence is documented procedures "that include timely updates to Microsoft until the issue is resolved and provides a post-incident review".
• Item 36 — "Where Microsoft is a Controller of Microsoft Personal Data, establish a formal complaint process for responding to all data protection complaints involving Microsoft Personal Data."

The SSPA Program Guide Version 12 gives the current procedure to report a data incident (page 18). The supplier reports through SupplierWeb or by email to [email protected]. The report includes these items:

• the data incident date
• the supplier name and the supplier number
• "Microsoft contact(s) notified"
• "Associated PO, if applicable/available"
• a summary of the data incident

The Program Guide adds: "Failure to provide evidence and/or respond to incident requests may result in an SSPA Status of Red (noncompliant)." For AI Systems, item 56 adds a second cause for notice: see AI Systems.

AI Systems

Microsoft DPR Version 10, Section K, gives the AI Systems requirements that MFF-8 and OFF-8 adapt. DPR Version 12 changes Section K: see DPR Version 10 and Version 12.

Section K applies only to suppliers that supply services to Microsoft involving AI Systems (applicability condition). For the independent assurance for Section K, see Independent assessments.

DPR Version 10 defines these terms for Section K (Key Definitions, pages 2 and 3):

• Intended Uses — "the primary purposes for which customers, suppliers, or end users are expected to use the system".
• Sensitive Use — "when the reasonably foreseeable use or misuse of an AI System could affect an individual" in one of three ways: "Consequential impact on legal position or life opportunities", "Risk of physical or psychological injury", or "Threat to human rights". DPR Version 12 does not use this term.
• Red Teaming — "an approach where a group of testers come together and intentionally probe a system to identify its limitations, risk surface, and vulnerabilities".

The Section K items use different modal words, for example "must", "will", and "should".

Item	Requirement column	Evidence of Compliance column
53	"Where AI Systems are included in connection with providing a service, Supplier must have the applicable AI Systems terms in place with Microsoft." "Any change to the Intended Uses must disclosed without undue delay and reviewed at least annually for accuracy and compliance."	"AI Systems contractual terms present in contract between Microsoft and Supplier."
54	"Assign responsibility and accountability for troubleshooting, managing, operating, overseeing, and controlling the AI System during and after deployment to a designated person or group within the company."	"Name the role of the person or group charged with ensuring compliance for AI Systems." "A document describing the authority and accountability of this person or group."
55	"Establish, maintain, and perform annual privacy and security training for anyone that will have access to or Process data within AI Systems by supplier in connection with Performance."	Annual records of attendance. "Training content is validated annually."
56	"Supplier has an AI System incident response plan that requires supplier to notify Microsoft per contractual requirements, as described by applicable privacy law, or without undue delay, whichever is sooner, upon becoming aware of a Data Incident or a discovered failure that would adversely impact any of the Intended Uses and Sensitive Uses listed for an AI System."	A plan "across all endpoints" with a step to notify Microsoft. The plan also has a "System rollback plan", "Support for turning features off", the procedure to update each model, and the procedure to tell customers, partners, and end users about "changes to the system, updated understandings of failures, and their best mitigations". The plan gives three times: "time elapsed until the entire system can be rolled back", "time elapsed until the feature can be turned off", and "time elapsed until the system has been updated".
57	"Supplier must have Red Teaming of AI Systems. Vulnerabilities must be addressed prior to AI System deployment."	Documentation that "Red Teaming processes are in place" and that "Vulnerabilities have been addressed".
58	"Supplier has a Responsible AI program to ensure data compliance through disclosures and documentation".	"Supplier has documentation describing the Responsible AI program."
59	"Supplier has Intended Uses Transparency disclosures."	"Intended Uses Transparency disclosures provided to Microsoft upon request."
60	"When engaging with AI Suppliers, organizations should establish clear contractual terms in a signed agreement." This item uses "should". It is a recommendation.	"Supplier will furnish documentary evidence to Microsoft upon request, including the agreement, if applicable."
61	"Define clear lines of accountability and responsibilities for AI deployment and risk management within the organization. Organizations must identify responsible parties for the outcomes of AI Systems."	"Supplier has a document describing the Responsible AI program, including accountability and responsibilities of person or group."
62	"Conduct privacy, security, and/or Responsible AI risk assessment to consider potential biases, security vulnerabilities, and unintended consequences. If any Sensitive Uses are included, guidance for required controls or mitigations must be included."	"Supplier will maintain evidence of risk assessments, or similar documentation or reporting including testing, monitoring of system evolution, and ongoing maintenance annually".
63	"AI Systems must be transparent and explainable. Supplier must provide insights into how decisions are made. Disclosures should encourage transparency in model architecture, training data, and decision-making processes."	"Supplier is to log all system failure reports, corruption, hallucinations, or reported misuse that detracts from the intended purpose, and provide evidence of steps taken to resolve the issues."
64	"Supplier must demonstrate continuous monitoring of AI Systems and adapt and update the AI Systems as new risks emerge." This continuous monitoring applies to the AI Systems.	The same evidence as item 63.
65	"Supplier must provide required disclosures, reporting, or other similar documentation with all required error types, performance metrics definitions, data performance, safety, and reliability indicators for each Intended Use."	Seven items, for example "acceptable error ranges", "Sensitive Use cases", controls against "automation bias", and mitigations "for well-known AI risks".
66	"Supplier will update the transparency disclosures, including Sensitive Use and Intended Uses, and notify Microsoft if" one of five events occurs: "new uses are added", "functionality changes", "the product moves to a new release stage", "new information about reliable and safe performance that impact Intended Use are discovered or applied", or "new information about system accuracy and performance becomes available".	"Supplier has a plan when updating transparency disclosures that includes a step to notify Microsoft as described in this section."
67	"Supplier must document a standard operating procedure and system health monitoring action plan for each AI system or data model". The plan has six items, for example "which events will be monitored", "the expected frequency of those reviews", and "third party AI components, including open source software, are kept up to date".	"Supplier has documented system health monitoring policies and procedures it will follow for each AI system as described in this section."
68	"Establish and document a detailed inventory of the system health monitoring methods to be used". The methods include "processes by which customers can submit information about failures and concerns" and "processes by which the general public can submit feedback".	"Supplier has documented system health monitoring methods as described in this section."
69	"If evidence is discovered that the AI system is not fit for the Intended Use(s) at any point before or during the system's use", the supplier does three steps. The first step has three alternatives: "remove the Intended Use from customer-facing materials and make current customers aware of the issue", "take action to close the identified gap", or "discontinue the system". The second and third steps are to "revise documentation related to the Intended Use" and to "publish the revised documentation to customers".	"Supplier has documented policies and procedures it will follow for a failure of Intended Use as described in this section."
70	"Supplier must identify and disclose all known demographic groups, including marginalized groups, who may be at risk of experiencing worse or adverse quality of service based on the Intended Use(s) of the AI System, geographic areas where the AI System will be deployed, or inherent biases within the AI System."	"Supplier must identify and document any justifiable factors" for "any inability to meet any target minimum performance level for any identified demographic group" and for "any remaining performance differences between identified demographic groups".

The Glossary of DPR Version 10 defines Human Oversight as "the Supplier designated category of Human Oversight and level of intervention available if failures are detected within the AI system for the Intended Uses". The Glossary gives three categories: human-in-the-loop, human-on-the-loop, and human-in-command. The definition alone adds no numbered requirement. The oversight duty of item 54 and the accountability duty of item 61 apply as written.

Next steps

Microsoft Supplier DPR in Modulos

MFF-8 and OFF-8, the Requirements, and the recommended sequence of work

When the DPR applies

Contracts, data, Subcontractors, transfers, and the Data Processing Profile

Reports and exports

Export functions in Modulos

Evidence

Evidence in Modulos

Sources

• Microsoft Supplier Data Protection Requirements, Version 10, October 2024 — Microsoft: Applicability, Key Definitions, Supplier Response, Sections A (items 3 and 4), G, I, J, and K, and the Glossary. PDF.
• Supplier Security & Privacy Assurance (SSPA) Program Guide, Version 12, March 2026 — Microsoft Procurement: pages 3 to 7 and 11 to 18. PDF.
• "SSPA: Supplier Security & Privacy Assurance Program" — Microsoft Procurement web page, with no date: "About SSPA". Web page.

Disclaimer

This page gives general information. It is not legal advice.