Features Frameworks Guide Pricing

Frameworks · Global

Microsoft SSPA

Microsoft's Supplier Security & Privacy Assurance (SSPA) program sets the privacy, security and AI requirements for suppliers that process Microsoft personal or confidential data or use AI systems in their work for Microsoft. Requirements are published in the Microsoft Supplier Data Protection Requirements (DPR); enrolled suppliers attest to them every year, and those handling higher-risk data may also need an independent assessment. The supplier's data processing profile decides which requirements apply, so controllers, suppliers handling only confidential data and suppliers without AI systems may answer a reduced set.

Version
Microsoft Supplier Data Protection Requirements v12 (March 2026)
Requirements
74, each mapped to ProofTrail’s controls
Try it in the demo $20 a year per installation

Requirements and controls

  • Section A Management

    • 1 Data protection terms in Microsoft agreements

      Make sure each agreement with Microsoft carries privacy and security terms for the data involved, including a ban on selling Microsoft personal data, and that processors describe the processing in the agreement.

      • Contractual Obligations Register
      • Data Protection Policy & Procedure
      • Statutory, Regulatory & Contractual Compliance

    • 2 Data protection agreements for subprocessors

      Where Microsoft designates the supplier as a subprocessor, sign the data protection agreements Microsoft requires, such as standard contractual clauses or a data processing addendum.

      • Contractual Obligations Register
      • Cross-Border Data Transfers
      • Statutory, Regulatory & Contractual Compliance

    • 3 Annual privacy, security and AI training

      Train everyone with access to Microsoft personal or confidential data on privacy and security every year, add role-relevant AI training for people using AI systems, and keep attendance records.

      • Security & Privacy Awareness
      • New Hire Security & Privacy Training
      • Periodic Security & Privacy Training

    • 4 Sanctions for policy violations

      Have consequences, up to dismissal, for staff who ignore the privacy and security rules, including Microsoft rules that apply when they work inside Microsoft.

      • Code of Business Conduct
      • Human Resources Policy & Procedure
      • Information Security & Privacy Policies

    • 5 Processing only on Microsoft's instructions

      Treat Microsoft's written instructions as the limit of what may be done with its personal data, transfers abroad included, and warn Microsoft before acting on any conflicting legal obligation.

      • Contractual Obligations Register
      • Data Protection Policy & Procedure
      • Cross-Border Data Transfers

  • Section B Notice

    • 6 Privacy notice when collecting data for Microsoft

      Show the Microsoft privacy statement clearly, before people submit anything, whenever personal data is collected on Microsoft's behalf, unless the supplier is the controller.

      • Published Privacy Policy
      • Privacy Notices on Data Collection Forms

  • Section C Choice and consent

    • 7 Consent and preference management

      Get each person's recorded agreement before collecting their data for a given use, and apply any change of preference within the shortest deadline local law allows.

      • Consent Management

    • 8 Cookie consent and notice

      Get the legally required consent before setting cookies or similar trackers, and give clear cookie notice and choice on Microsoft-branded sites and apps.

      • Consent Management
      • Published Privacy Policy

  • Section D Collection

    • 9 Collecting only what is needed

      Collect only the Microsoft personal or confidential data the engagement actually needs, and keep watching collection to make sure it stays that way.

      • Personal Data Inventory
      • Privacy by Design Policy

    • 10 Children's data

      Where children's personal data is involved, secure the consent that local law demands before any of it is collected.

      • Consent Management
      • Data Protection Impact Assessments

    • 11 Preserving de-identified data

      Leave pseudonymized, aggregated or anonymized data from Microsoft as it arrived and make no attempt to link it back to individuals.

      • Data Protection Policy & Procedure
      • Privacy by Design Policy

  • Section E Retention

    • 12 Retention limits

      Delete Microsoft personal and confidential data once the engagement no longer needs it, keeping it longer only where a law obliges the supplier to.

      • Data Retention Policy

    • 13 Return or secure destruction

      Return or destroy Microsoft data at the end of the work or on request, delete it securely from applications, and destroy physical media so it cannot be reconstructed.

      • Data Retention Policy
      • Media Disposal Policy

  • Section F Data subjects

    When individuals exercise their legal rights over Microsoft personal data, the supplier either enables Microsoft to act or acts on its behalf.

    • 14 Supporting data subject requests

      Give Microsoft prompt practical help with privacy rights requests, and send people who come to the supplier directly on to Microsoft unless told otherwise.

      • Data Subject Requests

    • 15 Verifying requester identity

      Check that people asking to exercise their rights are who they say they are, whether the supplier answers them directly or through a self-service tool.

      • Data Subject Requests

    • 16 Locating personal data on request

      When Microsoft asks for a person's data that self-service tools cannot reach, look for it properly and keep proof of where the search went.

      • Data Subject Requests
      • Personal Data Inventory

    • 17 Telling individuals how to exercise rights

      Give people clear directions on how to see or otherwise act on their Microsoft personal data.

      • Data Subject Requests
      • Published Privacy Policy

    • 18 Recording rights requests

      Keep a dated log of rights requests and the response to each, put refusals in writing when Microsoft asks, and hand the log to Microsoft on request.

      • Data Subject Requests

    • 19 Providing copies of personal data

      Make it possible for an authenticated person to receive their Microsoft personal data, through Microsoft or directly, in a usable format.

      • Data Subject Requests

    • 20 Protecting other people's data in responses

      Strip out anything that would reveal other people before handing data over in answer to a request.

      • Data Subject Requests

    • 21 Accuracy disputes

      Pass any complaint that Microsoft personal data is wrong or incomplete to Microsoft and help put it right.

      • Data Subject Requests

    • 22 Record of data recipients

      Track which organizations and people receive Microsoft personal data, so access requests can say where it went.

      • Personal Data Inventory
      • Processor Data Protection Agreements

  • Section G Subcontractors

    Applies when the supplier uses subcontractors to process Microsoft personal or confidential data.

    • 23 Notice before subcontracting

      Give Microsoft advance notice before any subcontractor starts handling Microsoft data or the set of subcontractors changes.

      • Contractual Obligations Register
      • Vendor Management Policy & Procedure

    • 24 Flow-down of contract terms

      Bind each subcontractor by written contract to privacy and data protection obligations that match or exceed what the supplier owes Microsoft.

      • Processor Data Protection Agreements
      • Vendor Management Policy & Procedure
      • Subservice Organization Evaluation

    • 25 Documenting subcontracted data

      Keep a description of the Microsoft data each subcontractor handles and why the work needs it.

      • Personal Data Inventory
      • Third-Party Criticality Assessments

    • 26 Limiting subcontractor processing

      Allow subcontractors to use Microsoft data only for the contracted work, adding a business associate agreement when health data is involved.

      • Processor Data Protection Agreements
      • Vendor Management Policy & Procedure

    • 27 Reporting subcontractor misuse

      Alert Microsoft promptly when a subcontractor turns out to have used Microsoft data outside the contracted work.

      • Management Review of Third-Party Risks
      • Breach Risk Assessment & Notification
      • Contractual Obligations Register

    • 28 Checking third-party data sources

      When gathering personal data for Microsoft from other sources, first check that those sources protect data in line with the Microsoft contract and the DPR.

      • Third-Party Criticality Assessments
      • Subservice Organization Evaluation
      • Vendor Management Policy & Procedure

  • Section H Quality

    • 29 Data accuracy and integrity

      Keep Microsoft personal data correct, up to date and fit for the purposes it was collected for.

      • Personal Data Inventory
      • Data Subject Requests

  • Section I Monitoring and enforcement

    • 30 Incident response and notification

      Maintain an incident response plan that notifies Microsoft of a data incident within the contractual or legal deadline, or without undue delay, cooperate with its investigation and keep security contacts current.

      • Incident Management Policy & Procedure
      • Incident Tracking
      • Breach Risk Assessment & Notification
      • Data Breach Notification Policy
      • Automated Incident Reporting

    • 31 Incident remediation

      Track every data incident through a remediation plan until the fix is confirmed, so corrective actions do not stall.

      • Incident Tracking
      • Incident Management Policy & Procedure

    • 32 Privacy complaint process

      Where Microsoft is the controller, give people a defined route for raising data protection complaints about Microsoft personal data, and answer each one.

      • Privacy Officer
      • Data Subject Requests
      • Incident Reporting Assistance

  • Section J Security

    The supplier runs a security program for Microsoft data. Microsoft accepts a valid ISO 27001 certificate in place of this section.

    • 33 Annual security risk assessment

      Assess risks to Microsoft data every year, review major changes such as new components, network or firewall changes, and keep change logs.

      • Risk Framing
      • Risk Assessment
      • Management Review of Risks
      • Change Management Policy & Procedure
      • Secure System Modification

    • 34 Mobile device policy

      Publish and enforce rules for phones and tablets that touch Microsoft data, restricting what they may hold or reach and how they are secured.

      • Endpoint Security Policy
      • Inventory of Endpoint Assets
      • Session Lock
      • Endpoint Encryption

    • 35 Asset inventory and ownership

      Keep an inventory of the physical and virtual assets used for the work, with an owner, acceptable use rules and protection throughout each asset's life.

      • Inventory of Infrastructure Assets
      • Inventory of Endpoint Assets
      • Asset Inventory Updates
      • Asset Ownership Assignment
      • Rules of Behavior

    • 36 Access rights management

      Control who can reach Microsoft data through defined steps for requesting, approving, reviewing and removing access.

      • Access Control Policy & Procedure
      • Identity Validation
      • Termination of Employment
      • User Privilege Reviews
      • User Access Reviews
      • Production System Access Review

    • 37 Patch and vulnerability management

      Prioritize and apply security patches, including emergency ones, scan for vulnerabilities every month, track exceptions and retire unsupported software.

      • Vulnerability Remediation Process
      • Centralized Flaw Remediation
      • Endpoint Security Validation
      • Vulnerability Management Policy & Procedure

    • 38 Anti-malware

      Keep up-to-date anti-malware running on all servers and desktops, Linux included, on networks that handle Microsoft data, with signatures refreshed daily.

      • Malware Protection

    • 39 Security by design

      Treat security as a design requirement from the start when building software or applications for Microsoft.

      • Change Management Policy & Procedure
      • Approval of Changes
      • Input Range Validation
      • Privacy by Design Policy

    • 40 Data loss prevention and intrusion detection

      Operate a data loss prevention program that classifies and labels data, uses intrusion detection and prevention, monitors for compromise, and reminds departing staff not to take Microsoft data.

      • Anomalous Behavior Detection
      • Centralized Security Logging
      • Unauthorized Activity Monitoring
      • Data Classification Labels
      • Data Classification Policy
      • Incident Management Policy & Procedure

    • 41 Network protection

      Secure networks with access controls, encrypted transmission and segmentation, keep network diagrams and baseline configurations current, and give network administration to dedicated roles.

      • External System Connections
      • Limit Network Connections
      • Transmission Confidentiality
      • Network Security Policy & Procedure
      • Network & Data Flow Diagrams
      • Segregation of Duties

    • 42 No hard-coded secrets

      Keep credentials and keys out of source code and build artifacts, loading them from a secrets store at runtime instead.

      • Secrets Kept Out of Source Code
      • Approval of Changes

    • 43 Protected backups

      Treat backups as sensitive: restrict who can reach them and protect the Microsoft data in them from tampering, leaks and loss.

      • Data Backup Policy
      • Data Backups
      • Encryption of Data at Rest

    • 44 Business continuity and disaster recovery

      Have plans for keeping the business running and restoring systems after a major disruption, and exercise them.

      • Disaster Recovery Policy
      • Business Continuity Policy & Procedure
      • Disaster Recovery Testing
      • Backup Restoration Testing

    • 45 Authentication and least privilege

      Require people to prove who they are before they reach Microsoft data, and give each of them only the access their tasks call for.

      • Multi-Factor Authentication
      • Access Control Policy & Procedure
      • Identity Validation
      • Production Database Access Restriction

    • 46 Identity verification during hiring and placement

      Confirm throughout hiring and placement that the person interviewed is the person hired and placed with Microsoft, and that their address details are consistent.

      • Hiring Identity Verification
      • Personnel Screening

    • 47 Encryption in transit

      Send data only over encrypted channels such as TLS or IPsec, and turn away any Microsoft data that arrives unprotected.

      • Transmission Confidentiality
      • Encryption Policy & Procedure

    • 48 Full disk encryption

      Encrypt the whole drive of every laptop and desktop used to work with Microsoft data.

      • Full Device Encryption
      • Endpoint Encryption

    • 49 Encryption at rest

      Store Microsoft personal and confidential data only in encrypted form using current standards, with special attention to credentials, payment, health and government ID data.

      • Encryption of Data at Rest
      • Encryption Policy & Procedure

    • 50 Anonymized test data

      Never put real Microsoft personal data into development or test systems; de-identify it first.

      • Test Data Protection

  • Section K AI systems

    Applies only to suppliers whose work for Microsoft involves AI systems.

    • 51 AI terms and intended uses

      Sign Microsoft's AI system terms when AI is part of the service, and report, then re-check every year, any change to what the AI is meant to be used for.

      • AI System Inventory & Resources
      • AI Transparency & User Information
      • Contractual Obligations Register

    • 52 Prohibited AI practices

      Keep AI systems used for Microsoft work clear of any practice that AI rules prohibit, from design through to use.

      • AI System Impact Assessment
      • AI Management System Scope & Roles

    • 53 AI incident response

      Plan how AI-related incidents are handled, including telling Microsoft quickly about data incidents or faults that undermine what an AI system is meant to do.

      • AI System Monitoring & Event Logs
      • Incident Management Policy & Procedure
      • Incident Tracking

    • 54 Transparency disclosures

      Publish documentation that tells users what each AI system in the work does and where its limits lie.

      • AI System Inventory & Resources
      • AI Transparency & User Information

    • 55 Agreements with AI suppliers

      Put contracts with AI vendors in writing and make them cover how data is treated, secrecy, ownership of outputs, liability and incident handling.

      • Vendor Management Policy & Procedure
      • Third-Party Criticality Assessments
      • AI System Impact Assessment
      • AI Management System Scope & Roles

    • 56 AI accountability

      Name owners for running, overseeing and managing the risks of each AI system, who deal with bias and ethics issues and arrange regular model audits.

      • AI System Impact Assessment
      • AI Management System Scope & Roles

    • 57 AI risk assessment

      Examine the privacy, security and responsible AI risks of each AI system, such as bias, weaknesses and side effects nobody intended.

      • AI System Impact Assessment
      • AI Management System Scope & Roles
      • Risk Framing
      • Risk Assessment

    • 58 Transparency and explainability

      Be able to show how each AI system arrives at its results, with information on how the model is built and what it was trained on.

      • AI System Inventory & Resources
      • AI Transparency & User Information

    • 59 Monitoring and adaptation

      Keep watching how AI systems behave in use and change them when new risks surface.

      • AI System Monitoring & Event Logs

    • 60 Performance documentation

      For every intended use, document how the system can fail and how well it performs, including safety and reliability measures.

      • AI System Inventory & Resources
      • AI Transparency & User Information

    • 61 Keeping disclosures current

      Refresh AI documentation and let Microsoft know whenever new uses, feature changes, a new release stage or new performance or safety findings come along.

      • AI System Inventory & Resources
      • AI Transparency & User Information

    • 62 AI operating procedure and health monitoring

      Write a runbook for each AI system that sets out how it is monitored, how failures are reproduced and prioritized, how feedback is gathered, and how third-party and open source parts are kept patched.

      • AI System Monitoring & Event Logs

    • 63 Handling AI systems unfit for use

      When an AI system turns out not to work for a stated use, drop or fix that use, warn current customers and republish corrected documentation.

      • AI System Monitoring & Event Logs