Jaa

Microsoft 365 Certification Submission Guide

  • Artikkeli

In this article:

Introduction

Part of the Microsoft 365 App Compliance program, the Microsoft 365 Certification offers assurance and confidence to enterprise organizations that data and privacy are adequately secured and protected when integrating third-party developer apps/add-ins into the Microsoft 365 platform. Applications and add-ins that pass validation will be designated Microsoft 365 Certified throughout the Microsoft 365 ecosystem.

By participating in the Microsoft 365 Certification program, you're agreeing to these supplemental terms and to comply with any accompanying documentation that applies to your participation in the Microsoft 365 Certification program with Microsoft Corporation ("Microsoft", "we", "us", or "our"). You represent and warrant to us that you have the authority to accept these Microsoft 365 Certification supplemental terms on behalf of yourself, a company, and/or other entity, as applicable. We may change, amend or terminate these supplemental terms at any time. Your continued participation in the Microsoft 365 Certification program after any change or amendment means you agree to the new supplemental terms. If you don't agree to the new supplemental terms or if we terminate these supplemental terms, you must stop participating in the Microsoft 365 Certification program.

This document is aimed at ISVs (Independent Software Vendors) to provide information on the Microsoft 365 Certification process, prerequisites to starting the process and details of specific security controls that ISVs must have in place.General information of the Microsoft 365 App Compliance program can be found under the Microsoft 365 App Compliance program page.

Important

Currently, Microsoft 365 Certification is applicable to all:

  • Microsoft Teams applications (Tabs, Bots, etc.) .
  • Sharepoint Apps/Add-ins
  • Office Add-ins (Word, Excel, PowerPoint, Outlook, Project, OneNote)
  • WebApps

Prerequisites

Publisher Attestation

Before being awarded the Microsoft 365 Certification process, you must have completed Publisher Attestation. However, you may start the Microsoft 365 Certification process prior to completing Publisher Attestation.

Read the Microsoft 365 Certification Specification

Microsoft recommends all ISVs (Independent Software Vendor) to read this Microsoft 365 Certification Specification in its entirety to ensure all applicable controls are being met by the in-scope environment and the app/add-in. This will help ensure a smooth assessment process.

Microsoft 365 Certification Specification Updates

Updates to the Microsoft 365 Certification specification are anticipated approximately every six to 12 months. These updates might introduce new target security domains and / or security controls. Updates will be based on developer feedback, changes to the threat landscape, and to increase the security baseline of the program as it matures.

ISVs that have already started the Microsoft 365 Certification assessment can continue the assessment with the version of the Microsoft 365 Certification Specification that was valid when the assessment was started. All new submissions, including annual recertification, will be required to be assessed against the version published.

Note

You are not required to comply with all the controls within this Microsoft 365 Certification Specification to be awarded a certification. However, passing thresholds (which will not be disclosed) are in place for each of the security domains discussed within this Microsoft 365 Certification Specification. Some controls will be classed as a ‘Hard Fail’ which means the lack of these security controls will result in a failed assessment.

Certification Scope

The in-scope environment is the environment that supports delivery of the app/add-in code and supports any backend systems that the app/add-in may be communicating with. Any additional connected-to environments will also be included in scope unless adequate segmentation is in place AND the connected-to environments can't impact the security of the in-scope environment. Any disaster recovery environments will also need to be included within the scope of the assessment as these environments would be required to fulfill the service should anything happen to the primary environment.The term in-scope system components reference ALL devices and systems that are used within the in-scope environment. In-scope components include, but aren't limited to:

  • The web application(s).
  • Servers.
  • Firewalls (or equivalent).
  • Switches.
  • Load balancers.
  • Virtual infrastructure.
  • Cloud provider web management portals

Important

The in-scope environment, must have a DMZ and the supporting environment of the app/add-in must be segmented from the internal business systems and corporate environments thus limiting the scope of the assessment activities to the in-scope systems only. Certification analysts will validate segmentation techniques during the assessment along with reviewing penetration testing reports which should have included testing to validate the effectiveness of any segmentation techniques in use.

Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)

Where IaaS and/or PaaS is used to support the infrastructure of the application or add-in code delivery under review, the Cloud platform provider will be responsible for some of the security controls assessed throughout the certification process. Therefore, certification analysts will need to be provided with independent external verification of security best practices by the Cloud platform provider through external compliance reports such as [PCI DSS] Attestation of Compliance (AOC), ISO27001 or [SOC 2] Type II reports.

Appendix F provides details of what security controls will likely be applicable based on the following deployment types and based upon whether the app/add-in exfiltrates Microsoft 365 data or not:

  • ISV Hosted
  • IaaS Hosted
  • PaaS/Serverless Hosted
  • Hybrid Hosted
  • Shared Hosted

Where IaaS or PaaS is deployed, you'll need to provide evidence of the environment being hosted within these deployment types.

Sampling

Requests for evidence in support of the certification assessment should be based on a sample of the in-scope system components in consideration of different operating systems, primary function of the device, and different device types. A suitable sample will be selected at the start of the certification process. The following table should be used as a guide on what the sample size may be:

Population Size Sample
<5 1
>5 & <10 2
>9 & <25 3
>24 4

Note

If discrepancies are identified between devices included within the initial sample, the sample size may be increased during the assessment.

Certification Process

Before starting the certification process, you'll need to have successfully completed your Publisher Attestation. Once complete, your Microsoft 365 Certification process proceeds as follows:

Preparation

  1. Navigate to partner center and review your completed Publisher Attestation documentation. If necessary, you can edit and update your responses; however, if you do so, you'll need to resubmit your attestation documentation for approval. If your submission is older than three months, we'll require that you resubmit Publisher Attestation for review and validation.
  2. Carefully read through the Microsoft 365 Certification Submission Guide to understand what will be required of you. Ensure that you'll be able to fulfill the control requirements specified in the Microsoft 365 Certification Submission Guide.
  3. Within partner center, select "Start Certification". This will bring you to your initial document submission portal. Submit your Initial Document Submission. This will help us determine what is in-scope for your assessment based on how your app is architected and handles customer data. Check this page frequently to see if your submission has been accepted.

Note

For all office apps you can reference our Office Apps User Guide. For all WebApps you can reference our SaaS App User Guide.

Assessment

  1. Once your initial document submission has been accepted the set of security controls required for your app will be automatically displayed in the portal. You'll then be required to submit evidence for each control demonstrating that the control is in place. Keep in mind you'll be given 60 days to submit all evidence. An analyst will review your evidence and either approve the control or request new or additional evidence. Check this page frequently to see if your evidence has been accepted.

Certification

  1. Once your submission has been validated by an analyst, you'll be notified of your certification decision. Apps awarded a certification will receive a badge on their application within AppSource, and Microsoft docs pages. You can read about the full benefits of certification here.

Review and Recertification

If your application undergoes Significant changes at any point you'll be required to notify us.

You'll also be required to go through recertification on an annual basis. This will require the revalidation of the in-scope controls against your current environment. This process can begin up to 90 days before the expiration of your certification. Your existing certification won't expire during the recertification period. Recertification across all programs expires on the one-year anniversary of your Microsoft 365 Certification.

If your certification isn't renewed before the expiration date, your apps certification status will be revoked. All badging, icons, and associated certification branding will be removed from your app, and you'll be prohibited from advertising your app as Microsoft 365 Certified.

Important

Submission time frame: It is anticipated that on average the assessment process should take 30 days, provided you are able to check your submission status frequently and respond to comments and supplemental evidence requests within a timely manner. Upon starting the certification process, a maximum of 60 days is permitted to complete the assessment. If all submissions have not been completed within the 60-day time-period, the submission will be issued a failure and the process must start again. These results will not be made public.

Initial Document Submission

The initial document submission will help certification analysts perform scoping and determine what will be in scope for your assessment. After which you'll be required to submit supporting documentation and evidence used to carry out the assessment. Your initial submission must include the information specified below. For additional guidance, see the Initial Document Submission Guide.

Documentation Overview Documentation Details
App/Add-in Description A description of the app/add-in’s purpose and functionality. This should provide the certification analyst with a good understanding of how the app/add-in functions and what it's intended use is
Penetration Testing Report A penetration testing report completed within the last 12 months. This report must include the environment that supports the deployment of the app/add along with any additional environment that supports the operation of the app/add-in. Note: if you don't do annual penetration testing, you can elect to have them done through the certification process.
Architecture diagrams A logical architecture diagram representing a high-level overview of your app's / add-in’s supporting infrastructure. This must include all hosting environments and supporting infrastructure supporting the app/add-in. This diagram MUST depict all the different supporting system components within the environment to help certification analysts understand systems in scope and help to determine sampling. Please also indicate what hosting environment type is used; ISV Hosted, IaaS, PaaS, or Hybrid. Note: Where SaaS is used, please indicate the various SaaS services that are used to provide the supporting services within the environment.
Public Footprint Detailing all public IP Addresses and URLs used by the supporting infrastructure. This must include the full routable IP range allocated to the environment unless adequate segmentation has been implemented to split the range in use (adequate evidence of segmentation will be required)
Data flow diagrams Flow diagrams detailing the following:
✓ Microsoft 365 Data flows to and from the App / Add-in (including EUII and OII ).
✓ Microsoft 365 Data flows within the supporting infrastructure(where applicable)
✓ Diagrams highlighting where and what data is stored, how data is passed to external third parties(including details of what third parties), and how data is protected in transit over open/public networks and at rest.
API Endpoint Details A complete listing of all API Endpoints used by your app. To help understand the environment scope, provide API endpoint locations within your environment.
Microsoft API Permissions Provide documentation detailing ALL the Microsoft APIs that are used along with what permissions are being requested for the app/add-in to function along with a justification for the requested permissions
Data storage types Data storage and handling documents describing:
✓ To what extent is your customers Microsoft 365 Data EUII and OII is being received and stored
✓ The data retention period.
✓ Why the customer Microsoft 365 Data is being captured.
✓ Where customer Microsoft 365 Data is stored (should be included within data flow diagrams supplied above).
Compliance confirmation Supporting documentation for external security frameworks included within the Publisher Attestation submission or to be considered when reviewing Microsoft 365 Certification controls. Currently, the following three are supported:
✓ PCI DSS Attestation of Compliance (AOC).
✓ SOC 2 Type I/Type II reports.
✓ ISMS / IEC - 1S0/IEC 27001 Statement of Applicability (SoA) and Certification.
Web Dependencies Documentation listing all dependencies used by the app / add-in with the current running versions.
Software Inventory An up-to-date software inventory that includes all software used within the in-scope environment along with the versions.
Hardware Inventory An up-to-date hardware inventory used by the supporting infrastructure. This will be used to help with sampling when performing the assessment phase. If your environment includes PaaS provide details of services consumed.

Evidence Collection and Assessment Activities

Certification analysts will need to review evidence across all system components within the defined sample set. The types of evidence required to support the assessment process include any or all the following:

Evidence Collection

  • Initial documentation, highlighted within the Initial Documentation Submission section above
  • Policy documents
  • Process documents
  • System configuration settings
  • Change tickets
  • Change control records
  • System reports

Various methods will be used to collect the evidence necessary to complete the assessment process. This evidence collection may be in the form of:

  • Documents
  • Screenshots
  • Interviews
  • Screensharing

The evidence collection techniques used will be determined during the assessment process. For concrete examples of the type of evidence required in your submission, see the Sample Evidence Guide.

Assessment Activities

Certification analysts will review evidence you provide to determine if you have adequately met controls within this Microsoft 365 Certification Specification.

Where possible and to reduce the amount of time required to complete the assessment, any or all of the documentation detailed in the Initial Documentation Submission should be provided in advance.

Certification analysts will first review the evidence provided from the initial documentation submission and the Publisher Attestation information to identify appropriate lines of inquiry, sampling size, and the need for further evidence to be obtained as detailed above. Certification analysts will analyze all information gathered to draw conclusions as to how and if you're meeting the controls within this Microsoft 365 Certification Specification.

App Certification Criteria

Your app, supporting infrastructure, and supporting documentation will be assessed across the following security domains:

  1. Application Security
  2. Operational Security / Secure Deployment
  3. Data Handling Security and Privacy

Each of these security domains includes specific key controls encompassing one or more specific requirements that will be evaluated as part of the assessment process. To ensure that Microsoft 365 Certification is inclusive to developers of all sizes, each of the security domains is assessed using a scoring system to determine an overall score from each of the domains. Scores for each of the Microsoft 365 Certification controls are allocated between 1 (low) and 3 (high) based upon the perceived risk of that control not being met. Each of the security domains will have a minimum percentage mark to be deemed a pass. Certain elements of this specification include some automatic fail criteria:

  • API permissions not following the principle of least privilege (PoLP).
  • No penetration testing report when it's required.
  • No anti-malware defenses
  • Multi-Factor authentication not being used to protect administrative access.
  • No patching processes.
  • No suitable GDPR privacy notice.

Application Security

The application security domain focuses upon the following three areas:

  • GraphAPI Permission Validation
  • External Connectivity Checks
  • Application Security Testing

GraphAPI Permission Validation

GraphAPI permission validation is carried out to validate the app/add-in doesn't request overly permissive permissions. This is carried out by manually checking what permissions are requested. Certification analysts will cross reference these checks against the Publisher Attestation submission and evaluate the level of access being requested to ensure ‘least privilege’ practices are being met. Where certification analysts believe these ‘least privilege’ practices aren't being met, certification analysts will have an open discussion with you to validate the business justification for the permissions being requested. Any discrepancies against your Publisher Attestation submission found during this review will also get feedback so your Publisher Attestation can be updated.

External Connectivity Checks

As part of the assessment, an Analyst will perform a light walk-through of the applications functionality to identify connections outside of Microsoft 365. Any connections that aren't identified as being Microsoft or direct connections to your service will be flagged and discussed during the assessment.

Application Security Testing

An adequate review of the risks associated with your app/add-in and supporting environment is essential in providing customers with assurance in the security of the app/add-in. Application security testing in the form of penetration testing MUST be carried out if your application has any connectivity to any service not published by Microsoft. If your app operates standalone without connectivity to any non-Microsoft service or backend, then penetration testing isn't required.

Penetration Testing Scope

Penetration testing activities MUST be conducted on the live production environment that supports the deployment of the app/add-in (for example; where the app/add-in code is hosted which will typically be the resource within the manifest file) along with any additional environment that supports the operation of the app/add-in (for example; if the app/add-in talks to other web applications outside of Microsoft 365). When defining the scope, care needs to be taken to ensure that any "connected-to" systems or environments that can impact upon the security of the in-scope environment is also included within ALL penetration testing activities.

Where techniques are used to segment the in-scope environments from other environments, penetration testing activities MUST validate the effectiveness of said segmentation techniques. This must be detailed within the penetration testing report.

Penetration testing reports will be reviewed to ensure there are no vulnerabilities that meet the following automatic failure criteria outlined in the controls below.

Penetration testing Requirements

Criteria Type Penetration Test Controls
General Criteria Controls
Application and infrastructure penetration testing MUST take place annually (every 12 months) and conducted by a reputable independent company.
Remediation of identified critical and high-risk vulnerabilities MUST be completed within one month of the conclusion of the penetration testing, or sooner depending on the documented patching process. 
The full external footprint (IP Addresses, URLs, API Endpoints, etc.) MUST be included within the scope of penetration testing and must be documented within the penetration testing report.
Web application penetration testing MUST include all vulnerability classes; for example, the most current OWASP Top 10 or SANS Top 25 CWE.
Retesting of identified vulnerabilities by the penetration testing company isn't required—remediation and self-review is sufficient however, adequate evidence to demonstrate sufficient remediation MUST be provided during the assessment.
Automatic Failure Criteria: Controls
Presence of an unsupported operating system.
Presence of default, enumerable, or guessable administrative accounts.
Presence of SQL injection risks.
Presence of cross-site scripting.
Presence of directory traversal (file path) vulnerabilities.
Presence of HTTP vulnerabilities, for example, Header response splitting, Request smuggling, and Desync attacks.
Presence of source code disclosure (including LFI).
Any critical or high score as defined by the CVSS patch management guidelines.
Any significant technical vulnerability that can be readily exploited to compromise a large amount of EUII or OUI.

Important

Reports must be able to provide enough assurance that everything detailed within the Application Security Test Specification section can be demonstrated.

Complimentary Penetration Testing Requirements and Rules

  • For ISVs that currently don't engage in penetration testing, penetration testing can be conducted free of charge the Microsoft 365 Certification. Microsoft will arrange and cover the cost of a penetration test for up to 12 days of manual testing. Penetration tests costs are calculated based on the number of days required to test the environment. Any expenses exceeding 12 days of testing will be the responsibility of the ISV.
  • ISVs will be required to submit evidence and receive approval for 50% of controls in-scope prior to the penetration test being conducted. To get started, fill out your initial document submission and elect to have penetration testing included as part of your assessment. You'll be contacted to scope and schedule your penetration test when you've completed 50% of the controls.
  • The report issued once the pentest is complete will be provided to the ISV once they have completed certification. This report along with your Microsoft 365 Certification can be used to show prospective customers your environment is secure.
  • ISVs will also be responsible for demonstrating that vulnerabilities identified in the penetration test have been remediated prior to a certification being awarded, but don't need to produce a clean report.

Once a penetration test is arranged, the ISV is responsible for fees associated with rescheduling and cancellations as follows:

Rescheduling Fee Timescale Proportion Payable
Reschedule request received more than 30 days prior to scheduled start date. 0% Payable
Reschedule request received 8 to 30 days prior to scheduled start date. 25% Payable
Reschedule request received within 2 to 7 days prior to scheduled start date with a firm rebooking date. 50% Payable
Reschedule request received less than 2 days before the start date. 100% Payable
Cancellation Fee Timescale Proportion Payable
Cancellation request received more than 30 days prior to scheduled start date. 25% Payable
Cancellation request received 8 to 30 days prior to scheduled start date. 50% Payable
Cancellation request received within 7 days prior to scheduled start date. 90% Payable

Operational Security

This domain measures the alignment of your app's supporting infrastructure and deployment processes with security best practices.

Controls

Control Family Controls
Malware Protection - Antivirus Provide policy documentation that governs anti-virus practices and procedures.
Provide demonstrable evidence that anti-virus software is running across all sampled system components.
Provide demonstratable evidence that anti-virus signatures are up-to-date across all environments (within 1 day).
Provide demonstratable evidence that anti-virus is configured to perform on-access scanning or periodic scan across all sampled system components. Note: If on-access scanning is not enabled, then a minimum of daily scanning and alerting MUST be enabled.
Provide demonstratable evidence that anti-virus is configured to automatically block malware or quarantine and alert across all sampled system components.
Application Controls: ONLY required if traditional anti-malware isn't used Provide demonstratable evidence that applications are approved prior to being deployed.
Provide demonstratable evidence that a complete list of approved applications with business justification exists and is maintained.
Provide supporting documentation detailing that application control software is configured to meet specific application control mechanisms. (Example: Allowed listing: sample1, sample3, code signing)
Provide demonstratable evidence that application control is configured as documented from all sampled system components.
Patch Management - Risk Ranking Supply policy documentation that governs how new security vulnerabilities are identified and assigned a risk score.
Provide evidence of how new security vulnerabilities are identified.
Provide evidence demonstrating that all vulnerabilities are assigned a risk ranking once identified.
Patch Management - Patching Provide policy documentation for patching of in-scope system components that includes suitable minimal patching timeframe for critical, high, and medium risk vulnerabilities; and decommissioning of any unsupported operating systems and software.
Provide demonstratable evidence that all sampled system components are being patched.
Provide demonstratable evidence that any unsupported operating systems and software components aren't used within the environment.
Vulnerability scanning Provide the quarterly infrastructure and web application vulnerability scanning reports. Scanning needs to be carried out against the entire public footprint (IP addresses and URLs) and internal IP ranges.
Provide demonstratable evidence that remediations of vulnerabilities identified during vulnerability scanning are patched in line with your documented patching timeframe.
Firewalls Provide policy documentation that governs firewall management practices and procedures.
Provide demonstrable evidence that any default administrative credentials are changed prior to installation into production environments.
Provide demonstrable evidence that firewalls are installed on the boundary of the in-scope environment, and installed between the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) and internal trusted networks.
Provide demonstrable evidence that all public access terminates in the demilitarized zone (DMZ).
Provide demonstrable evidence that all traffic permitted through the firewall goes through an approval process.
Provide demonstrable evidence that the firewall rule base is configured to drop traffic not explicitly defined.
Provide demonstrable evidence that the firewall supports only strong cryptography on all non-console administrative interfaces.
Provide demonstratable evidence that you're performing firewall rule reviews at least every 6 months.
Web Application Firewall (WAF) (OPTIONAL): Additional credit will be rewarded for satisfying the following controls. Provide demonstratable evidence that the Web Application Firewall (WAF) is configured to actively monitor, alert, and block malicious traffic.
Provide demonstrable evidence that the WAF supports SSL offloading.
Provide demonstratable evidence that the WAF is protects against some, or all of the following classes of vulnerabilities as per the OWASP Core Rule Set (3.0 or 3.1)
Change Control Provide policy documentation that governs change control processes.
Provide demonstratable evidence that development and test environments enforce separation of duties from the production environment.
Provide demonstratable evidence that sensitive production data isn't used within the development or test environments.
Provide demonstratable evidence that documented change requests contain impact of the change, details of back-out procedures and of testing to be carried out.
Provide demonstratable evidence that change requests undergo an authorization and sign out process.
Secure Software Development/Deployment Provide policies and procedures that support secure software development and deployment, including secure coding best practice guidance against common vulnerability classes such as, OWASP Top 10 or SANS Top 25 CWE.
Provide demonstratable evidence that code changes undergo a review and authorization process by a second reviewer.
Provide demonstratable evidence that developers undergo secure software development training annually.
Provide demonstratable evidence that code repositories are secured with multi-factor authentication (MFA).
Provide demonstratable evidence that access controls are in place to secure code repositories.
Account Management Provide policy documentation that governs account management practices and procedures.
Provide demonstratable evidence that default credentials are either disabled, removed, or changed across the sampled system components.
Provide demonstratable evidence that account creation, modification and deletion go through an established approval process.
Provide demonstratable evidence that a process is in place to either disable or delete accounts not used within 3 months.
Provide demonstratable evidence that a strong password policy or other suitable mitigations to protect user credentials are in place. The following should be used as a minimum guideline: minimum password length of 8 character, account lockout threshold of no more than 10 attempts, password history of a minimum of 5 passwords, enforcement of the use of strong password
Provide demonstratable evidence that unique user accounts are issued to all users.
Provide demonstratable evidence that least privilege principles are being followed within the environment.
Provide demonstratable evidence that a process is in place to secure or harden service accounts and the process is being followed.
Provide demonstratable evidence that MFA is configured for all remote access connections and all non-console administrative interfaces.
Provide demonstratable evidence that strong encryption is configured for all remote access connections and all non-console administrative interfaces, including access to any code repositories and cloud management interfaces.
Provide demonstratable evidence that MFA is used to protect the admin portal that you use to manage and maintain all public domain name service (DNS) records.
Intrusion Detection and Prevention (OPTIONAL): Additional credit will be rewarded for satisfying the following controls Provide demonstratable evidence that Intrusion Detection and Prevention Systems (IDPS) is deployed at the perimeter of the in-scope environments.
Provide demonstratable evidence that IDPS signatures are kept current (within 24 hours).
Provide demonstratable evidence that IDPS is configured to support TLS inspection of all incoming web traffic.
Provide demonstratable evidence that IDPS is configured to monitor all inbound traffic flows.
Provide demonstratable evidence that IDPS is configured to monitor all outbound traffic flows.
Security Event Logging Provide policy documentation for best practices and procedures that governs security event logging.
Provide demonstratable evidence that shows security event logging is set up across all sampled system components to log the following events: User access to system components and the application, All actions taken by a high-privileged user, Invalid logical access attempts Privileged account creation or modification, Event log tampering, Disabling of security tools (such as anti-malware or event logging), anti-malware logging (such as updates, malware detection, and scan failures)., IDPS and WAF events, if configured
Provide demonstratable evidence that logged security events contain the following minimum information: User, Type of event, Date and time, Success or failure indicators, Label that identifies the affected system
Provide demonstratable evidence that all sampled system components are time-synchronized to the same primary and secondary servers.
Provide demonstratable evidence when public facing systems are in use that security event logs are being sent to a centralized logging solution not within the perimeter network.
Provide demonstrable evidence to show that the centralized logging solution is protected against unauthorized tampering of logging data.
Provide demonstrable evidence that a minimum of 30 days of security event logging data is immediately available, with 90 days of security event logs being retained.
Security Event Log Reviews Provide policy documentation that governs log review practices and procedures.
Provide demonstrable evidence that logs are reviewed on a daily basis by a human or automated tooling to identify potential security events.
Provide demonstrable evidence that potential security events and anomalies are investigated and remediated.
Alerting Provide policy documentation that governs security event alerting practices and procedures.
Provide demonstrable evidence that alerts are triggered for immediate triage for the following types of security events: Privileged account creation or modifications, Virus or malware events, Event log tampering, IDPS or WAF events
Provide demonstrable evidence showing that staff is always available, all day, every day, to respond to security alerts.
Risk management Provide demonstratable evidence that a formal information security risk management process is established.
Provide demonstrable evidence that a formal risk assessment occurs annually, at a minimum.
Provide demonstrable evidence that the information security risk assessment includes threats, vulnerabilities, or the equivalent.
Provide demonstrable evidence that the information security risk assessment includes impact, likelihood risk matrix, or the equivalent.
Provide demonstrable evidence that the information security risk assessment includes a risk register and treatment plan.
Incident response Provide the security incident response plan (IRP).
Provide demonstrable evidence that the security IRP includes a documented communication process to ensure timely notification to key stakeholders, such as payment brands and acquirers, regulatory bodies, supervisory authorities, directors, and customers.
Provide demonstrable evidence that all member of the incident response team have completed annual training or a table top exercise.
Provide demonstrable evidence to show the security IRP is updated based on lessons learned or organizational changes.

Data Handling Security and Privacy

Data in transit between the application user, intermediary services, and ISV’s systems will be required to be protected by encryption through a TLS connection supporting a minimum of TLS v1.1.See Appendix A.

Where your application retrieves and stores Microsoft 365 data you'll be required to implement a data storage encryption scheme that follows the specification as defined in Appendix B.

Controls

Control Family Controls
Data in Transit Provide demonstratable evidence that TLS configuration meets or exceeds the encryption requirements within the TLS profile configuration requirements
Provide demonstratable evidence that TLS compression is disabled across all public-facing services that handle web requests.
Provide demonstratable evidence that TLS HTTP strict transport security is enabled and configured to >= 15552000 across all sites.
Data at Rest Provide demonstratable evidence that data at rest is encrypted inline with the encryption profile requirements, using encryption algorithms such as AES, Blowfish, TDES and encryption key sizes of 128-bit, and 256-bit.
Provide demonstratable evidence that hash function or message authentication (HMAC-SHA1) is only used to protect data at rest inline with encryption profile requirements.
Provide an inventory showing all stored data, including storage location and encryption used to protect the data.
Data Retention and Disposal Provide demonstratable evidence that an approved and documented data retention period is formally established.
Provide demonstratable evidence that retained data matches defined retention period.
Provide demonstratable evidence that processes are in place to securely delete data after its retention period.
Data Access Management Provide a list of all individuals with access to data or encryption keys, including the business justification.
Provide demonstratable evidence that the sampled individuals who have access to data or encryption keys were formally approved, detailing privileges required for their job function.
Provide demonstratable evidence that the sampled individuals who have access to data or encryption keys only have the privileges included in the approval.
Provide a list of all third-parties that customer data is shared with.
Provide demonstratable evidence that all third-parties consuming customer data have sharing agreements in place.
GDPR (If Applicable) Provide a documented subject access request (SAR) process and provide evidence demonstrating that data subjects are able to raise SARs.
Provide demonstratable evidence that you're able to identify all locations of data subjects' data when responding to a SAR.
You maintain a privacy notice that should contain the companies details (Name, Address, etc..).
You maintain a privacy notice that should explain the types of personal data being processed.
You maintain a privacy notice that should explain the lawfulness of processing personal data
You maintain a privacy notice that explains in details the data subject's rights: Right to be informed, Right of access by the data subject, Right to erasure, Right to restriction of processing, Right to data portability, Right to object, Rights in relation to automated decision-making, including profiling.
You maintain a privacy notice that should explain how long personal data will be kept for.

Optional External Compliance Frameworks Review

Although it isn't required, if you're currently in compliance with ISO 27001, PCI DSS, or SOC2, you can elect to use these certifications to satisfy some of the Microsoft 365 Certification controls. Certification analysts will try to align existing external security frameworks to the Microsoft 365 Certification specification. However, if supporting documentation is unable to provide assurance that Microsoft 365 Certification controls were assessed as part of the external security frameworks audit/assessment you'll need to provide additional evidence of the said controls being in place.

Documentation must adequately demonstrate that the in-scope environment for the Microsoft 365 Certification was included within the scope of these external security frameworks. Validation of these security frameworks will be fulfilled by accepting evidence of valid certifications conducted by reputable external third-party companies. These reputable companies must be members of international accreditation bodies for relevant compliance programs. See ISO Certification and Conformity Standards for ISO 27001 and Qualified Security Assessors (QSA) for PCI DSS.

The following table highlights the external frameworks and documentation required by certification analysts as part of this validation process:

Standard Requirements
ISO 27001 A public facing version of the Statement of Applicability (SOA) and a copy of the ISO 27001 certificate issued will be required.The SOA summarizes your position on each of the 114 information security controls and will be used to identify if any exclusion of controls that aren't satisfactorily detailed in the ISO 27001 certificate. If this can't be determined by reviewing the public facing version of the SOA, the analyst might need access to the full SOA if ISO 27001 will be used to validate some of the Microsoft 365 Certification Specification controls. In addition to validating the scope of the ISO 27001 assessment activities, the analysts will also confirm the validity of the audit company as described above.
PCI DSS A valid Level 1 Attestation of Compliance (AOC) document must be provided clearly identifying the in-scope application and system components.A self-assessment AOC will not be accepted as evidence of meeting security best practices. The AOC will be used to determine which of the Microsoft 365 Certification Specification controls have been evaluated and confirmed as part of the PCI DSS assessment.
SOC 2 The SOC 2 (Type I or Type II) report must be current (issued within the last 15 months and the declared time period started within the last 27 months) to be used as evidence of conformity with any of the assessment controls within this Microsoft 365 Certification Specification.

If external security frameworks have been included within the Publisher Attestation, certification analysts will need to check the validity of those security compliance frameworks as part of the Microsoft 365 Certification assessment.

Framework Additional considerations
ISO 27001 Appendix C: Evidence Collection – Deltas for ISO 27001.
PCI DSS Appendix D: Evidence Collection – Deltas for PCI DSS.
SOC 2 Appendix E: Evidence Collection – Deltas for SOC 2.

Note

Although the above-mentioned external security standards/frameworks can be submitted as evidence to meet some of the Microsoft 365 Certification controls, passing the Microsoft 365 Certification doesn't mean that you will successfully pass an audit against those standards/frameworks. The Microsoft 365 Certification Specification is only a small subset of those security standards/frameworks that allows Microsoft to gain a level of assurance in reference to your security posture.

Requirements to use external compliance frameworks

✓ The App/Add-in supporting environment AND any supporting business processes MUST be included within the scope of any supported external security compliance frameworks and must be clearly indicated in supplied documentation.

✓ Supported external security compliance frameworks MUST be current, that is, within the past 12 months (or within 15 months if the reassessment is currently being carried out and evidence can be provided).

✓ Supported external security compliance frameworks MUST be carried out by an independent accredited company.

Appendix A

TLS Profile configuration requirements

All network traffic, whether within a virtual network, cloud service, or a data center, must be protected with a minimum of TLS v1.1 (TLS v1.2+ is recommended) or other applicable protocol. Exceptions to this requirement are:

  • HTTP-to-HTTPS redirect. Your app can respond over HTTP to redirect clients to HTTPS, but the response must not contain any sensitive data (cookies, headers, content). No other HTTP responses other than redirects to HTTPS and responding to health probes are allowed. See below.
  • Health probes. Your app can respond to health probes over HTTP only if HTTPS health probes aren't supported by the checking party.
  • Certificate access. Access to CRL, OCSP, and AIA endpoints for the purposes of certificate validation and revocation checking is allowed over HTTP.
  • Local communications. Your app can use HTTP (or other non-protected protocols) for communications that don't leave the operating system, e. g. connecting to a web server endpoint exposed on localhost.

TLS Compression MUST be disabled.

Appendix B

Encryption Profile Configuration Requirements

Only cryptographic primitives and parameters are permitted as follows:

Symmetric cryptography

Encryption

 ✓ Only AES, BitLocker, Blowfish or TDES are allowed. Any of the supported key lengths >=128 are allowed (128 bits, 192 bits, and 256 bits) and may be used (256-bit keys are recommended).

 ✓ Only CBC mode is allowed. Every encryption operation must use a fresh, randomly generated initialization vector (IV).

 ✓ Use of stream ciphers, such as RC4, IS NOT allowed.

Hash functions

 ✓ All new code must use SHA-256, SHA-384, or SHA-512 (collectively referred to as SHA-2). Output may be truncated to no less than 128 bits

 ✓ SHA-1 may only be used for compatibility reasons.

 ✓ Use of MD5, MD4, MD2 and other hash functions IS NOT allowed, even for non-cryptographic applications.

Message authentication

 ✓ All new code MUST use HMAC with one of the approved hash functions. Output of HMAC may be truncated to no less than 128 bits.

 ✓ HMAC-SHA1 may only be used for compatibility reasons.

 ✓ HMAC key MUST be at least 128 bits. 256-bit keys are recommended.

Asymmetric algorithms

Encryption

 ✓ RSA is allowed. Key MUST be at least 2048 bits and OAEP padding must be used. Use of PKCS padding only allowed for compatibility reasons.

Signatures

 ✓ RSA is allowed. Key MUST be at least 2048 bits and PSS padding must be used. Use of PKCS padding only allowed for compatibility reasons.

 ✓ECDSA is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

Key Exchange

 ✓ ECDH is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

 ✓ ECDH is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

Appendix C

Evidence Collection – Delta for ISO 27001

Where you have already attained ISO27001 compliance, the following delta’s (gaps) not wholly covered by ISO 27001 will, at a minimum, need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of your Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped ISO 27001 controls were not included as part of the ISO 27001 assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from the ISO 27001 will need to be included within your Microsoft 365 Certification assessment activities.

Malware Protection – Anti Virus

If malware protection is in place using application control and is attested to within ISO 27001 Report no further investigation is necessary. If no application control is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Demonstrate that anti-virus software is running across all sampled system components.

  • Demonstrate that anti-virus is configured across all sampled system components to either automatically block malware, to quarantine & alert or to alert.

  • Anti-virus software MUST be configured to log all activities.

Patch Management – Patching

As ISO 27001 audits don't specifically assess this category, this will require you to:

  • Software components and operating systems no longer supported by the vendor MUST not be used within the environment. Supporting policies MUST be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place

Vulnerability Scanning

As ISO 27001 audits don't specifically assess this category, this will require you to:

  • Demonstrate that quarterly internal and external vulnerability scanning is conducted.

  • Confirm supporting documentation is in place for vulnerability remediation based on risk ranking and in line with the specification as follows:

✓ Fix all Critical and Highs risk issues in-line with the risk ranking for Internal scanning.

✓ Fix all Critical, Highs and Medium risk issues in-line with the risk ranking for external scanning.

✓ Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies)

As ISO 27001 audits don't specifically assess this category, this will require you to:

  • Demonstrate that firewalls are installed on the boundary of the in-scope environment.

  • Demonstrate that firewalls are installed between the DMZ and trusted networks.

  • Demonstrate that all public access terminates in the DMZ.

  • Demonstrate that default administrative credentials are changed prior to installation into the live environment.

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process, which results in the documentation of all traffic with a business justification.

  • Demonstrate that all firewalls are configured to drop traffic not explicitly defined.

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

  • Demonstrate that firewall rule reviews are conducted at least every 6 months

Firewall – Web Application Firewalls (WAF)

Additional credit will be provided if a WAF is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL Offloading.

  • Is configured as per the OWASP Core Rule Set (3.0 or 3.1) to protect against most of the following attack types:

✓ Protocol and encoding issues.

✓ Header injection, request smuggling, and response splitting.

✓ File and path traversal attacks.

✓ Remote file inclusion (RFI) attacks.

✓ Remote code execution attacks.

✓ PHP-injection attacks.

✓ Cross-site scripting attacks.

✓ SQL-injection attacks.

✓ Session-fixation attacks.

Change Control

As ISO 27001 audits don't specifically assess some elements of Change Request processes, this will require you to:

  • Demonstrate that change requests have the following details:

✓ Documented impact.

✓ Details of what functionality testing is to be conducted.

✓ Details of any back-out procedures.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Account Management

As ISO 27001 audits don't specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how ✓s are implemented to mitigate replay attacks (for example, MFA, Kerberos).
  • Demonstrate how accounts that haven't been used in 3 months are either disabled or deleted.
  • ✓or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

✓ Minimum password length of 8 characters.

✓ Account lockout threshold of no more than 10 attempts.

✓ Password history of a minimum of five passwords.

✓ Enforcement of the use of strong passwords.

  • Demonstrate that MFA is configured for all remote access solutions.

  • Demonstrate that strong encryption is configured on all remote access solutions.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL)

As ISO 27001 audits don't specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS SHOULD be deployed at the perimeter of the supporting environment.

  • IDPS signatures SHOULD be kept current, within the past day.

  • IDPS SHOULD be configured for TLS inspection.

  • IDPS SHOULD be configured for ALL inbound and outbound traffic.

  • IDPS SHOULD be configured for alerting.

Event Logging

As ISO 27001 audits don't specifically assess some elements of security event logging processes, this will require you to:

  • Demonstrate that public facing systems are logging to a centralized logging solution that isn't within the DMZ.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days being retained.

Reviewing (Logging Data)

As ISO 27001 audits don't specifically assess some elements of this category, this will require you to:

  • Demonstrate how daily log reviews are conducted and how exceptions and anomalies are identified showing how these are handled.

Alerting

As ISO 27001 audits don't specifically assess some elements of this category, this will require you to:

  • Demonstrate how security events are configured to trigger alerts for immediate triage.

  • Demonstrate how staff are available 24/7 to respond to security alerts.

Risk Management

As ISO 27001 audits don't specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate that a formal risk management process is established.

Incident Response

As ISO 27001 audits don't specifically assess some elements of incident response policies and processes, this will require you to:

  • Demonstrate that the incident response plan/procedure includes:

✓ Specific response procedures for expected threat models.

✓ Incident handling capabilities aligning to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

✓ The IRP covers the in-scope systems.

✓ Annual training for the incident response team.

Appendix D

Evidence Collection – Deltas for PCI DSS

Where you have already attained PCI DSS compliance, the following delta’s (gaps) not wholly covered by PCI DSS will, at a minimum, need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of the Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped PCI DSS controls were not included as part of the PCI DSS assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from the PCI DSS will need to be included into the Microsoft 365 Certification assessment activities.

Malware Protection - Application Control

If malware protection is in place through use of anti-virus and is attested to within PCI DSS Report no further investigation is necessary. If no anti-virus is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (that is, allowlisting, code signing, etc.).

  • Demonstrate that across all sampled system components, application control is configured as documented.

Patch Management – Risk Ranking

As PCI DSS audits don't specifically assess this category, this will require you to:

  • Demonstrate how risk ranking of vulnerabilities is conducted.

Vulnerability Scanning

As PCI DSS audits don't specifically assess this category, this will require you to:

  • Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies)

As PCI DSS audits don't specifically assess this category, this will require you to:

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

Additional credit will be provided if a Web Application Firewall (WAF) s deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set (3.0 or 3.1) to protect against most of the following attack types:

✓ Protocol and encoding issues.

✓ Header injection, request smuggling, and response splitting.

✓ File and path traversal attacks.

✓ Remote file inclusion (RFI) attacks.

✓ Remote code execution attacks.

✓ PHP-injection attacks.

✓ Cross-site scripting attacks.

✓ SQL-injection attacks.

✓ Session-fixation attacks.

Change Control

As PCI DSS audits don't specifically assess some elements of Change Request processes, this will require you to:

  • Demonstrate that change requests are raised before being made in production environments.

  • Demonstrate that changes are authorized before going into production.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Secure Software Development/Deployment

As PCI DSS audits don't specifically access some elements of secure software development and deployment processes; this will require to you:

  • Code repositories MUST be secured by MFA.

  • Adequate access controls MUST be in place to protect code repositories against malicious code modifications.

Account Management

As PCI DSS audits don't specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (for example, MFA, Kerberos).

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

✓ Minimum password length of 8 characters.

✓ Account lockout threshold of no more than 10 attempts.

✓ Password history of a minimum of five passwords.

✓ Enforcement of the use of strong passwords.

  • Demonstrate that strong encryption is configured on all remote access solutions.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL)

As PCI DSS audits don't specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS SHOULD be configured for TLS inspection.

  • IDPS SHOULD be configured for ALL inbound and outbound traffic.

Risk Management

As PCI DSS audits don't specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate the risk assessment includes impact and likelihood matrices.

Incident Response

As PCI DSS audits don't specifically assess some elements of incident response policies and processes, this will require the developer to:

  • Demonstrate Incident handling capabilities align to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

Appendix E

Evidence Collection - Deltas for SOC 2

Where you have already attained SOC 2 compliance, the following delta’s (gaps) not wholly covered by SOC 2 will need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of the Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped SOC 2 controls were not included as part of your SOC 2 assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from your SOC 2 assessment will need to be included as part of the Microsoft 365 Certification assessment activities.

Malware Protection - Application Control

If malware protection is in place through use of anti-virus and is attested to within your SOC 2 report no further investigation is necessary. If no anti-virus is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (that is, allowlisting, code signing, etc.).

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Demonstrate that across all sampled system components, application control is configured as documented.

Patch Management – Patching

As SOC 2 audits don't specifically assess this category, this will require you to:

  • Any Low, Medium, High, or Critical issue must be patched within normal patching activity windows.

  • Software components and operating systems no longer supported by the vendor MUST not be used within the environment. Supporting policies MUST be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place.

Firewall – Firewalls

As SOC 2 audits don't specifically assess change controls to firewall access control lists, this will require you to:

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process that results in the documentation of all traffic with a business justification.

  • Demonstrate that firewall rule reviews are conducted at least every six months.

Additional credit will be provided if a Web Application Firewall (WAF) or similar is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set ((3.0 or 3.1) to protect against most the following attack types:

 ✓ Protocol and encoding issues.

 ✓ Header injection, request smuggling, and response splitting.

 ✓ File and path traversal attacks.

 ✓ Remote file inclusion (RFI) attacks.

 ✓ Remote code execution attacks.

 ✓ PHP-injection attacks.

 ✓ Cross-site scripting attacks.

 ✓ SQL-injection attacks.

 ✓ Session-fixation attacks.

Change Control

As SOC 2 audits don't specifically assess some elements of Change Request processes, this will require the developer to:

  • Demonstrate how development / test environments are separate from the production environment enforcing separation of duties.

  • Demonstrate how live data isn't used within the development / test environments.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Secure Software Development/Deployment

As SOC 2 audits don't specifically access some elements of secure software development and deployment processes; this will require to you:

  • You MUST have an established and documented software development process covering the entire software-development lifecycle.

  • Developers MUST undergo secure software coding training at least annually.

  • Code repositories MUST be secured by MFA.

  • Adequate access controls MUST be in place to protect code repositories against malicious code modifications.

Account Management

As SOC2 audits don't specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (for example, MFA, Kerberos).

  • Demonstrate how accounts that haven't been used in 3 months are either disabled or deleted.

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

 ✓ Minimum password length of 8 characters.

 ✓ Account lockout threshold of no more than 10 attempts.

 ✓ Password history of a minimum of 5 passwords.

 ✓ Enforcement of the use of strong passwords

  • Demonstrate that unique user accounts are issued to all users.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL).

As SOC 2 audits don't specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS signatures SHOULD be kept current, within the past day

  • IDPS SHOULD be configured for TLS inspection

  • IDPS SHOULD be configured for ALL inbound and outbound traffic

Event Logging

As SOC 2 audits don't specifically assess some elements of security event logging processes, this will require you to:

  • Demonstrate how, on all system components within the sample set the following system are configured to log the following events

 ✓ User access to system components and the application(s).

 ✓ All actions taken by a high privileged user.

 ✓ Invalid logical access attempts.

Demonstrate that logged events contain; at a minimum, the following information:

 ✓ User.

 ✓ Type of Event.

 ✓ Date and Time.

 ✓ Success/Failure indicator.

 ✓ Label to identify the affected system.

  • Demonstrate that all system components within the sample set are configured to utilize time-synchronization and that these are the same as the primary/secondary time servers.

  • Demonstrate that public facing systems are logging to a centralized logging solution that isn't within the DMZ.

  • Demonstrate that public facing systems are logging to a centralized logging solution that isn't within the DMZ.

  • Demonstrate how the centralized logging solution is protected from unauthorized tampering of logging data.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days’ or more being retained.

Risk Management

As SOC2 audits don't specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate that a formal risk assessment is conducted at least annually.

Incident Response.

As SOC2 audits don't specifically assess some elements of incident response policies and processes, this will require you to:

  • Demonstrate that the incident response plan/procedure includes:

 ✓ Specific response procedures for expected threat models.

 ✓ Documented communications process to ensure timely notification of key stakeholders (payment brands/acquirers, regulatory bodies, supervisory authorities, directors, customers, etc.

Appendix F

Hosting Deployment Types

Microsoft acknowledges you'll deploy applications and store app/add-in code within different hosting environments. The overall responsibilities of some of the security controls within the Microsoft 365 Certification will depend on the hosting environment being used. Appendix F looks at common deployment types and maps these against the security controls that are evaluated as part of the assessment process. The following hosting deployment types have been identified:

Hosting Types Description
ISV Hosted ISV hosted types can be defined as where you're responsible for the infrastructure used to support the app/add-in environment. This can be physically located within your own data centers or third-party data centers with a co-location service. Ultimately, you have full ownership and administrative control over the supporting infrastructure and operating environment.
Infrastructure as a Service (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/) Infrastructure as a Service is a service that is provided whereby the physical supporting infrastructure is managed and maintained on their behalf by the cloud service provider (CSP). Typically, networking, storage, physical servers, and the virtualization infrastructure is all the responsibility of the CSP. The Operating System, Middleware, Runtime, Data and Applications are the responsibilities of you. Firewalling capabilities would also be managed and maintained by the third-party, however maintenance of the firewall rule base would usually be still the consumers responsibility.
Platform as a Service/Serverless (PaaS) (https://azure.microsoft.com/overview/what-is-paas/) With Platform as a Service, you're provisioned with a managed platform presenting a service that can be consumed. You don't need to perform sysadmin functions as the operating system and supporting infrastructure is managed by the CSP. This would typically be used when organizations don't want to be concerned with presenting a web service and instead can concentrate on creating the web application source code and publishing the web application on the cloud managed web services.Another example may be a database service where connectivity is given to a database, however the supporting infrastructure and database application is abstracted from the consumer.Note: Serverless and PaaS are similar so for the purpose of the Microsoft 365 Certification Hosting Deployment Type's Serverless and PasS are deemed the same
Hybrid Hosted With the hybrid hosted type, you may utilize multiple hosted types to support various parts of the supporting environment. This may be more the case where apps/add-ins are utilized across multiple Microsoft 365 stacks. Although the Microsoft 365 Certification will support where apps/add-ons across multiple Microsoft 365 services are developed, an assessment of the entire (across app/add-ins) supporting environment would need to be assessed in line with each of the applicable "Hosted Type Mappings". Occasionally, you may utilize different hosted types for a single add-in, where this is being carried out, applicability of criteria will need to still follow the "Hosted Type Mappings" criteria across the various hosted types.
Shared Hosting Shared hosting is where you're hosting the environment within a platform that shared by multiple individual consumers. The Microsoft 365 Certification Specification wasn't written to account for this due to the adoption of cloud, shared hosting isn't common. If you believe this is being used, please contact Microsoft as additional requirements will need to be created to account for the additional risks under this type of hosting type.

Appendix G

Learn more

Microsoft 365 App Compliance Program Overview What is Microsoft 365 App Publisher Attestation? What is Microsoft 365 Certification?

Glossary

AIA

*Authority Information Access is a service location descriptor used to find the certificate of the issuing certificate authority.

CRL

*Certificate Revocation List provide a means for a Secure Sockets Layer (SSL) endpoint to verify that a certificate received from a remote host is valid and trustworthy.

CVSS score

*Common Vulnerability Scoring System is a published standard that measures vulnerability and calculates a numerical score based on its severity.

CVSS patch management guidelines

  • Critical (9.0 - 10.0)
  • High (7.0 - 8.9)
  • Medium (4.0 - 6.9)
  • Low (0.0 - 3.9)

DMZ

*Demilitarized zone is a physical or logical intermediate network that interacts directly external or non-propriety networks while keeping the host's internal, private network separate and isolated.

EUII

End-user identifiable information.

GDPR

*General Data Protection Regulation is a European Union (EU) privacy and data protection regulation for all EU citizens’ data regardless of where your application site is located.

HSTS

*HTTP Strict Transport Security utilizes an HTTP response header instructing the web browser to only access content over HTTPS.This is designed to protect against downgrade attacks and cookie hijacking.

IEC

*International Electrotechnical Commission.

ISMS

*Information Security Management System.

ISV

Independent Security Vendors are individuals and organizations who develop, market and sell software that runs on third-party software and hardware platforms.

ISO 27001

An information security management system specification framework for all technical controls in an organizations risk management policies and procedures processes.

LFI

Local File Inclusion allows an attacker to include files on a server through the web browser.

NIST

The National Institute of Standards (NIST), a non-regulatory agency of the U.S. Department of Commerceprovides guidance for private sector organizations in the US to assess and approve their ability to prevent, detect, and respond to cyber attacks.

Non-Significant changes

  • Minor Bug fixes.
  • Minor performance improvements.
  • Operating systems/libraries/client and server application patches.

OCSP

Online Certificate Status Protocol is used to check the revocation status of X.509 digital certificates.

OII

Organizational identifiable information.

OWASP

Open Web Application Security Project.

PCI DSS

Payment Card Industry Data Security Standard, an organization that maintains standards for the safety of cardholder data worldwide.

Pen testing

Penetration testing is a method of testing a web app by simulating malicious attacks to find security vulnerabilities that an attacker could exploit.

SAML

Security Assertion Markup Language is s an open standard for exchanging authentication and authorization data between the user, the identity provider and the service provider.

Sensitive Data

  • Access control data.
  • Customer content.
  • End-user identity information.
  • Support data.
  • Public personal data.
  • End-user pseudonymous information.

Significant changes

  • Relocation of the hosting environment.
  • Major upgrades to the supporting infrastructure; for example, implementation of a new firewall, major upgrades to front facing services, etc.
  • Addition of capabilities and /or extensions to your app.
  • Updates to your app that capture additional sensitive Data.
  • Changes to your app's data flows or authorization models
  • Addition of API endpoints or API endpoint functions.

SOC 2

Service Organization Control 2, a technical auditing procedure comprised of five Trust Service Principles to ensure that service providers securely manage the data and privacy for an organization's clients.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.