Updated 6/18/24 to include changes made for version 9.1 of the SSPA program.

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.

May 2024 Updates to Requirement 53 in Version 9.1

Microsoft has added an urgent and risk-responsive requirement to version 9 of the SSPA program. This does not change the versioning from 9 to 10, but rather creates version 9.1 of the SSPA program, marking the first time a minor revision has been released.

According to the Microsoft SSPA team, “the new requirement stems from a recent privacy and security incident where a supplier developed a small-scale mobile application for Microsoft and they negligently left credentials in the software’s code, consequently leading to the data incident.” Requirement 53 will now require that suppliers ensure secrets are not embedded or hardcoded in the software at any stage of the development process.

Microsoft’s suggested evidence of compliance with requirement 53, is as follows:

  • Use of a supported and current version of a credential exposure prevention tool such as GitHub Advanced Security (GHAS) or similar service or tool.
  • Assurance that if source or configuration files did mistakenly include secrets, those secrets were documented as revoked upon discovery.
  • Assurance that any replacement or secondary credential was not pushed back into code.
  • Documentation of any false positives and their remediation.

Since many suppliers have already completed their self-attestation DPR and have independent assessments in-flight, there is a chance that the DPR or Independent Assessment Letter of Attestation tasks could be rejected by the SSPA team. If that happens the task(s) will go back into the supplier’s queue, and the supplier will see this new requirement in their DPR.

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 sspa@clarknuber.com 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.