A Beginner’s Guide to Microsoft’s SSPA Program and Independent Assessments
Strong privacy and security practices are the foundation of trust in today’s information-based economy. In a growing number of jurisdictions, such practices are even required by law. Microsoft’s Supplier Security and Privacy Assurance (SSPA) program can be a critical part of this effort. SSPA is a set of requirements and practices that all vendors (“suppliers”) that are part of Microsoft’s information supply chain must comply with to conduct business with Microsoft.
Making sense of SSPA and understanding how the requirements apply to a supplier’s specific business may seem daunting. But by first understanding the principles of the program, the path to compliance becomes much clearer. We answer several fundamental questions about SSPA and how suppliers can meet these requirements for doing business with Microsoft.
Who must comply with SSPA?
Any supplier that processes what Microsoft defines as Microsoft Personal Data or Microsoft Confidential Data must fulfill specific compliance requirements within SSPA. The level of those requirements, however, depends on the type of data the supplier processes while providing services to Microsoft and how that data is processed.
Microsoft defines “processing” as any operation or set of operations that is performed on any Microsoft Personal Data or Microsoft Confidential Data. That can include collecting or altering data, transmitting it to a third party, erasing or storing it, and a number of other uses.
What is Microsoft Personal Data under SSPA?
Microsoft defines Microsoft Personal Data more broadly than what some people think of as “personally identifiable information” (PII). Microsoft considers any data to be personal if it is linked or linkable to an individual. For example, answers to a consumer survey could exclude the respondent’s name but still be linkable to that individual when paired with enough demographic data. Data need not be “sensitive” (think Social Security numbers, ethnic origin, gender identity, etc.) to be considered Microsoft Personal Data. Even an individual’s email address could be Microsoft Personal Data under SSPA.
It is important to note that Microsoft Personal Data only includes data that a supplier processes as part of the services it provides to Microsoft. This could include data relating to a Microsoft employee, customer, job candidate, or prospective customer. Conversely, data regarding a supplier’s own employees or customers that is processed in the course of doing business not related to Microsoft—including payroll, login credentials of the supplier’s employees and customers, etc.—does not fall under the purview of SSPA and need not be reported when suppliers submit their information to Microsoft.
What is Microsoft Confidential Data under SSPA?
Microsoft Confidential Data can be defined broadly as any information about Microsoft that a supplier knows because of its business relationship with Microsoft and that the general public would not know. This includes items that are obviously sensitive, such as corporate financial data and trade secrets shared under a non-disclosure agreement. But Confidential Data under SSPA can also include marketing information available to a supplier before a product’s release and information obtained from manufacturing or testing parts of a Microsoft product.
Microsoft distinguishes Confidential Data from Highly Confidential Data, the latter of which is more sensitive and thus carries greater compliance requirements. Microsoft provides examples of Personal, Confidential, and Highly Confidential Data in its SSPA Program Guide. Note, however, that these are illustrative examples, not an exhaustive list. Microsoft may decide that items not included in this guide could trigger SSPA enrollment for a supplier.
What are SSPA tasks and when are they due?
Suppliers that wish to process Microsoft Personal or Confidential Data must enroll in the SSPA program before engaging with Microsoft. All enrolled suppliers are then required to complete SSPA compliance tasks annually. All enrollment and reenrollment activities are completed through Microsoft’s SSPA portal, which is called Aravo.
Microsoft will create compliance tasks in the portal based on the supplier’s Data Processing Profile. Events that may trigger new compliance tasks include the supplier’s initial enrollment, the anniversary of the supplier’s enrollment, or other changes that the supplier initiates to its Data Processing Profile. The specific compliance tasks that are assigned to the supplier depend on the attributes that the supplier has selected for its Data Processing Profile.
After a compliance task is triggered, the supplier has 90 days to complete the task. During that time, the supplier must respond to a questionnaire regarding the company’s compliance with each applicable Data Protection Requirement (DPR) under SSPA. The process of completing the questionnaire is called DPR Self-Attestation. During this phase, the supplier attests whether it is compliant with the DPRs and has an opportunity to explain why some DPRs may not apply to the supplier.
Suppliers requesting higher data processing approval levels through SSPA may be required to fulfill another task, called Audit Documentation. This task is due in the same 90-day window as the DPR Self-Attestation. There are multiple ways to satisfy the “Audit Documentation” task, including:
-
SSPA Independent Assessment
-
Evidence of a Type 2 SOC 2 examination
-
ISO 27001/27701 certification
-
A combination of the above measures
An SSPA Independent Assessment can take four to eight weeks, so suppliers need to act quickly. Given the 90-day window to satisfy the Audit Documentation requirement, it is critical for suppliers to initiate this process as soon as possible after being assigned the task. Suppliers can do so by contacting a Microsoft Preferred Assessor or another company that meets the requirements of the SSPA Program Guide.
SHARE