March 14, 2024

Protection of sensitive corporate and personal information is a dynamic and paramount business concern. Microsoft has leveraged their Supplier Security and Privacy Assurance (SSPA) program to address these concerns that intersect with their supplier network.

The SSPA program, and the accompanying Data Protection Requirements (DPR), are periodically updated to address evolving and emerging risks. Microsoft completed a revision to this program in October 2023 and published version 9 of the SSPA program guide and DPR on November 13, 2023. Compliance with this program is a major prerequisite to continue doing business with Microsoft; it is vitally important for suppliers to stay current with the changing SSPA requirements.

We have reviewed the updated DPR to highlight some important items to keep in mind: At a high level, the security and privacy themes in the program remain the same. There are still ten sections in the program and the themes have not changed. The number of requirements has increased from 50 to 52, with two requirements being added, none retired, and others receiving updates.

Furthermore, some specific observations are detailed below.

New Requirements (References to v9 Indexing):

#5 – Apply appropriate sanctions to employees who fail to comply with supplier’s privacy and security policies.

  • Best practice in policy design is to not only describe what behavior should and should not be conducted for policy compliance, but also to describe the consequences – or sanctions – for an employee’s non-compliance with the policy. Documentation in privacy and security policies will now need to describe sanctions for non-compliance (e.g., up to and including termination).

#13 – Where supplier receives a data set from Microsoft with reduced identifiability, including pseudonymous, Not in a Position to Identify (NPI), unlinked pseudonymous, aggregate, anonymous, or any term that relates to one of those classifications (such as de-identified), supplier will maintain the data in the state in which it was received.

  • The European Union General Data Protection Regulation (GDPR) considers that certain processors may receive data that does not identify a data subject, and that the processor is not obligated to acquire or process further data, for the sole purpose of complying with data subject rights protected by GDPR. SSPA Requirement #13 follows this logic but takes it a step further. To comply with this requirement a supplier will need to have policy language in place that prohibits increasing the identifiability of data sets (i.e., reidentify individuals who are part of a data set through joining with other data sets, etc.).

Updates to Other Requirements (References v8/v9 Indexing)

Version 9 of the SSPA program includes several modifications to requirements to clarify applicability ­­relative to Protected Health Information (PHI) and expected evidence of compliance. Changes to specific requirements are as follows:

v8/v9 IndexingWhat does the requirement relate to?What does the update entail?
#2/#2Suppliers that have been designated as SubprocessorsReferences a Business Associate Agreement (BAA) when PHI processing is involved.
#4/#4Annual security and privacy trainingReferences HIPAA training when PHI is involved.
#22/#24The provision of notice to Microsoft when a Supplier intends to use a SubcontractorAdds clarity that this relates to Subcontractors that may be used to process Confidential Data, as well as the previously included Personal Data.
#25/#27Limiting the data processed by SubcontractorsReferences the need to have a BAA between the Supplier and Subcontractor when PHI is involved.
#30/#32Data integrity for Personal DataAdds clarity to the evidence of compliance portion to demonstrate review of information system activity.
#34/#36The performance of an annual network security assessmentIncorporates language to include an assessment of the potential risks and vulnerabilities to Microsoft Personal Data. In addition, the requirement previously included the need to conduct vulnerability scans; this continues to be required but has been moved to requirement #40 (v9).
#36/#38Inventory of assets used in the processing of Microsoft DataAdds clarity to include virtual assets and devices to support security and operations in the asset inventory.
#37/#39Access rights managementThe Evidence of Compliance portion was updated to include automatic logoff after inactivity and deactivation of user accounts for subcontractors upon termination.
#38/#40Security patch managementMoves the vulnerability scan from requirement #36 (v9) and adds clarity that the vulnerability scans need to be monthly with a “high level compliance report.”
#39/#41Installation of anti-virus and anti-malware softwareAdds clarity that the anti-virus and anti-malware software should be regularly patched and up to date.
#41/#43Use of a Data Loss Prevention program (DLP), including use of Intrusion Detection SystemsAdds clarity that the DLP program needs to prevent intrusion/loss at the application, system, and infrastructure levels.
#43/#45Training for system administrators, operations staff, management and third partiesAdds clarity that this requirement also applies to anyone accessing Microsoft Personal or Confidential Data. In addition, the Evidence of Compliance portion was updated to include training on security reminders, address log-in monitoring, and safeguarding passwords when working with PHI.

Our overall impression is that these updates add clarity – especially as it relates to safeguarding PHI – and strengthens the security of Microsoft Data while maintaining the core content of the DPR framework.

Changes to the Independent Assessor’s Report

Microsoft has also added clarity to the contents and format of the Independent Assessment report. Overall, very similar information will be communicated to Microsoft. They have requested some consistency in the format of the report, as they will be using automated processes in the future to ingest these reports for increased efficiency and improved service in the acceptance phase of the compliance cycle. Noteworthy changes you can expect to see in our report format are as follows.

  • The form and content of the cover page will be the same but will now include the name and contact information of the assessor in charge of the assessment.
  • Page 2 of our report currently includes a table organized by Section of the SSPA Program, A-J. With this update, Microsoft has asked that this content be expanded and has suggested a table format which can be found on page 4 of the SSPA Preferred Assessors List. This table lists all of the requirements by number, and then in columns left-to-right includes:

a) a description of the procedure performed by the assessor (e.g., inquiry with supplier personnel, review of policies and procedures, and/or inspection of evidence)

b) the supplier’s response to the requirement in the DPR

c) the response resulting from the assessment (e.g., does this agree to the DPR submitted by the supplier or not)

d) assessor remarks (e.g., if a difference is reported, why is that correct)

Microsoft has asked that this format be implemented as soon as possible.

If you have any questions about these updates or any of the other SSPA literature, please contact us at and we would be happy to continue this conversation.

© Clark Nuber PS, 2024. All Rights Reserved.

This article contains general information only and should not be construed as accounting, business, financial, investment, legal, tax, or other professional advice or services. Before making any decision or taking any action, you should engage a qualified professional advisor.