Microsoft 365 Certification framework overview
This article provides detailed information, including the list of Microsoft 365 Certification security controls, and support for ISVs and developers undergoing Microsoft 365 Certification.
The Microsoft 365 Certification is an independent security and privacy audit of apps, add-ins, and supporting backend environment (collectively referred to as apps) integrating with the Microsoft 365 platform. Apps that pass will be designated Microsoft 365 Certified throughout the Microsoft 365 ecosystem and can be found easily in Microsoft 365 marketplaces via compliance focused search filters and branding. ISVs will have the opportunity to share their apps compliance attributes on dedicated pages within this documentation set.
Microsoft 365 Certification is available for the following types of applications:
- Microsoft 365 add-ins (Word, Excel, Outlook, PowerPoint, OneNote, Project)
- Teams apps
- SharePoint solutions
- Web apps (SaaS)
Important
Microsoft 365 Certification is a rigorous review of an app's security and compliance against the Microsoft 365 Certification framework and requires a substantial time and resource commitment to complete. Please review the compliance control frameworks to see if your app is eligible before starting certification. For any questions, please email appcert@microsoft.com.
Terms
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.
Prerequisites
Before Microsoft 365 Certification can be awarded, an app must complete the following:
Publisher verification When an app has a verified publisher, the organization that publishes the app has been verified as authentic by Microsoft. Verifying an app includes using a Microsoft Cloud Partner Program (CPP) account that's been verified and associating the verified PartnerID with an app registration. Get publisher verified
Publisher Attestation is a self-service process where ISVs answer a set of questions about their app’s security and data handling practices. Apps can be publisher attested in Microsoft Partner Center and receive badging and dedicated filters in Microsoft AppSource marketplace upon completion.
Review the control criteria It is not required to comply with all controls to be awarded a certification. However, thresholds (which will not be disclosed) are in place for each of the three security domains discussed within this overview document and must be passed. Some controls will be classed as a ‘hard fail’ which means the lack of these security controls will result in a failed assessment.
Important
Submission time frame: On average the assessment process should take 30 days, provided ISVs are able to check 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.
Certification scope
The in-scope environment supports delivery of the app/add-in code and supports any backend systems that the app/add-in may be communicating with. Any additional environments connected-to the in-scope environment 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 seperate disaster recovery environments will also need to be included within the in-scope environment as these environments would be required to fulfill the service should anything happen to the primary environment. Remote backup environments will also need to be included since these environments may store Microsoft Data and therefore adequate security controls will need to be in place.
The term in-scope system components reference ALL devices and systems that are used within the defined in-scope environment. In-scope components include, but aren't limited to:
- Web application(s)
- Servers (physical or virtual which can be on-prem or in the cloud)
- Network Security Controls (NSCs), such as firewalls
- Switches
- Load balancers
- Virtual infrastructure
- Cloud provider web management portals
- Cloud resources (Virtual Machines, App Service, Storage Accounts, EC2 Instances, etc..)
Important
Public facing system components are susceptible to attacks from external threat actors and are therefore at much greater risk. Typically, these systems would be segmented away from other internal system components using a network security control (NSC) creating a demilitarized zone (DMZ). The intention being that the DMZ is less trusted than the internal network and additional security would help further protect the internal systems and data should the public facing systems become compromised. Ideally a DMZ would be used, however this is not feasible or even necessary in some deployment scenarios.
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 in-scope environment under review, the Cloud platform provider will be responsible for some of the security controls assessed throughout the certification process. 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), ISO 27001 or SOC 2 Type II reports.
Appendix C provides details what security controls will likely be applicable based on the following types of deployment and based upon whether the app exfiltrates Microsoft 365 data:
- ISV Hosted
- IaaS Hosted
- PaaS/Serverless Hosted
- Hybrid Hosted
- Shared Hosted
Where IaaS or PaaS is deployed, evidence validating the environment's alignment to these deployment types must be provided.
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, different device types (i.e. Servers, NSCs, Routers, etc.) and location. A suitable sample will be selected at the start of the certification process. The following table should be used as a guide where sampling will be determined based on the factors detailed above:
| Population Size | Sample |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Note
If discrepancies are identified between devices included within the initial sample, the sample size may be increased during the assessment.
End-to-end certification process
To begin Microsoft 365 Certification:
Navigate to Partner Center and complete Publisher Attestation. If the submission is older than three months, please resubmit for review and validation.
Within partner center, select "Start Certification" to begin the initial document submission. This will help certification analysts determine what is in-scope for the assessment based on the app's architecture and how it handles Microsoft data.
Tip
Follow the how-to guide for step by step directions to get your app Microsoft 365 Certified.
The certification process is carried out over two stages as described below:
Initial Document Submission helps the analyst to understand the app, data flows, define the in-scope environment, identify what security controls are applicable and determine the system components that evidence will need to be collected from. The ISV must supply requested information to help the certification analyst complete this stage of the process, which is approximately 5% of the overall process.
Full Evidence Review is the process whereby the ISV submits evidence artifacts demonstrating how the in-scope environment is meeting the security controls. There will be multiple interactions between the ISV and the analyst during this audit stage which is the remainder of the process.
Assessment
Once the initial document submission has been accepted the set of security controls will be automatically displayed in the portal. ISVs must provide evidence for each control demonstrating that the control is in place and have 60 days to submit all evidence. An analyst will review the evidence and either approve the control or request new or additional evidence.
Certification
Once a submission has been validated by an analyst, ISVs are notified of the certification decision. Apps awarded a certification will receive a badge on their application within AppSource, and dedicated Microsoft docs pages with detailed reporting of their security and compliance attributes.
Review and recertification
Microsoft 365 Certified apps are required to go through recertification on an annual basis. This will require the revalidation of the in-scope controls against the current in-scope environment. This process can begin up to 90 days before the expiration of certification. Existing certifications will not expire during the recertification period. Recertification across all programs expires on the one-year anniversary of your Microsoft 365 Certification.
If the certification isn't renewed before the expiration date, the apps certification status will be revoked. All badging, icons, and associated certification branding will be removed from your app, and ISVs will be prohibited from advertising your app as Microsoft 365 Certified.
If an application undergoes significant changes outside of the recertification submission time frame ISV's are asked to notify the Microsoft App Compliance Program to any updates.
Initial document submission
Your initial submission must include the following information:
| 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 the ISV does not currently perform annual penetration testing, Microsoft will cover the cost of pen testing through the certification process. |
| Architecture diagrams | A logical architecture diagram representing a high-level overview of the app's supporting infrastructure. This must include all hosting environments and supporting infrastructure supporting the app. 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 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 Microsoft 365 Data EUII and OII is being received and stored | |
| ✓ The data retention period. | |
| ✓ Why the Microsoft 365 Data is being captured. | |
| ✓ Where Microsoft 365 Data is stored (should also 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 security controls. Currently, the following four 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. | |
| ✓ FedRAMP FedRAMP Authorization Package and FedRAMP Readiness Assessment Report. | |
| Web dependencies | Documentation listing all dependencies used by the app with 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 the cloud services/resource 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 guide
- Policy documents
- Process documents
- System configuration settings
- Change tickets
- Change control records
- System reports
- Meeting minutes
- Contracts/agreements
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 specific examples of the type of evidence required in your submission, see the Sample Evidence Guide.
Assessment activities
Certification analysts will review the evidence provided to determine if all controls for the Microsoft 365 Certification have been met.
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
The app and it's supporting infrastructure, and supporting documentation will be assessed across the following three security domains:
Each of these security domains includes specific key controls encompassing one or more 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 implemented. 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 is not being used to protect administrative access.
- No patching processes.
- No suitable GDPR privacy notice.
Application security
The application security domain focuses on three areas:
- GraphAPI Permission Validation
- External Connectivity Checks
- Penetration 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 the ISV to validate the business justification for the permissions being requested. Any discrepancies against the Publisher Attestation submission found during this review will need to be corrected.
External connectivity checks
As part of the assessment, a light walk-through of the applications functionality will be performed to identify any connections being made 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.
Penetration testing
An adequate review of the risks associated with the 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 once deployed your app operates standalone accessing only Microsoft service such as GraphAPI, then penetration testing isn't required. Penetration testing is still required if the in-scope environment is hosted within Azure.
Penetration testing scope
For both internal and external infrastructure penetration testing, all 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 environments that support 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 for penetration testing, 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.
It is recommended that web application penetration testing be conducted against the live production environment. However, it would be acceptable to carry out testing of only the web application using a test/UAT environment, providing it is confirmed within the penetration testing report that the exact same codebase was operating within the test/UAT environment at the time of testing.
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.
Note
Internal penetration testing must be carried out unless the hosting environment is only classed as PaaS.
Penetration testing requirements
Penetration testing reports will be reviewed to ensure there are no vulnerabilities that meet the following automatic failure criteria outlined in the controls below.
| Criteria Type | Penetration test controls |
|---|---|
| General criteria | Web application (authenticated and unauthenticated) and both internal (if applicable) and external 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 ISV's 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 clearly documented within the penetration testing report. | |
| Unless the environment aligns to PaaS, the full internal networks MUST be included within the scope of penetration testing and must be clearly 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. The recommendation is that this is detailed within the penetration testing report otherwise it will be difficult to demonstrate. | |
| Critical and high-risk vulnerabilities or vulnerabilities deemed as an automatic failure MUST be retested by the penetration testing company and clearly highlighted as fixed within the penetration testing report. | |
| Automatic failure criteria: | Presence of an unsupported operating system or unsupported JavaScript Library. |
| 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 penetration testing requirements section above 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 for 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 in-scope 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 pen-test 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 an app's supporting infrastructure and deployment processes with security best practices.
Controls
| Control family | Controls |
|---|---|
| Awareness training | Provide evidence the organization provides established security awareness training to information system users (including managers, senior executives, and contractors) as part of initial training for new users or when required by information system changes. |
| Provide evidence of an organization-defined frequency of awareness training. | |
| Provide evidence of documentation and monitoring of individual information system security awareness activities while retaining individual training records over an organization-defined frequency. | |
| Malware protection - antivirus | Provide evidence that your anti-malware solution is active and enabled across all the sampled system components and configured to meet the following criteria: |
| If anti-virus, that on-access scanning is enabled and that signatures are up-to-date within 1-day and it automatically blocks malware or alerts and quarantines when malware is detected. | |
| OR if EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus) then periodic scanning is being performed, audit logs are generated, and it is kept up-to date continually and has self-learning capabilities. | |
| If EDR/NGAV then it blocks known malware and it identifies and blocks new malware variants based on macro behaviors as well as having full safelist capabilities. | |
| Malware protection - application controls | Provide demonstratable evidence that an approved list of software/applications with business justification exists and is up to date. |
| That each application undergoes an approval process and sign off prior to its deployment | |
| That application control technology is active, enabled, and configured across all the sampled system components as documented. | |
| Patch management - patching and 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. | |
| Provide evidence that all sampled system components are being patchedin line with the organizations defined patching timeframes and unsupported operating systems and software components are not in use. Where applicable this should include code base if serverless technology or PaaS is used, or both infrastructure and code base if IaaS is used. | |
| Patching timeframe guidelines: Critical – within 14 days, High – Within 30 days, Medium – Within 60 days. | |
| 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. | |
| Network Security Controls (NSC) | Provide evidence that Network Security Controls (NSC) are installed on the boundary of the in-scope environment, and installed between the perimeter network and internal networks. |
| AND if Hybrid, On-prem, IaaS also provide evidence that all public access terminates at the perimeter network. | |
| Validate that all Network Security Controls (NSC) are configured to drop traffic not explicitly defined within the rule base and that Network Security Controls (NSC) rule reviews are carried out at least every 6 months. | |
| Change control | Provide evidence that any changes introduced to production environments are implemented through documented change requests which contain the impact of the change, details of back-out procedures, testing to be carried out, review and approval by authorized personnel. |
| Provide evidence that separate environments exist so that: development and test/staging environments enforce separation of duties from the production environment, separation of duties is enforced via access controls, sensitive production data is not in use within the development or test/staging environments. | |
| Secure software development/deployment | Provide policies and procedures that support secure software development and include industry standards and/or best practices for secure coding. Such as Open Web Application Security Project (OWASP) Top 10 or SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE). |
| Provide evidence that code repositories are secured so that: all code changes undergo a review and approval process by a second reviewer prior to being merged with main branch, appropriate access controls are in place, all access is enforced through multi-factor authentication (MFA) | |
| Provide evidence that all releases made into the production environment(s) are reviewed and approved prior to their deployment. | |
| Account management | Provide evidence that default credentials are either disabled, removed, or changed across the sampled system components. |
| Provide evidence a process is in place to secure (harden) service accounts and that this process has been followed. | |
| Provide evidence that: unique user accounts are issued to all users, user least privilege principles are being followed within the environment, a strong password/passphrase policy or other suitable mitigations are in place, a process is in place and followed at least every three months to either disable or delete accounts not used within three months. | |
| Validate that MFA is configured for all remote access connections and all non-console administrative interfaces, including access to any code repositories and cloud management interfaces. | |
| Security eventlogging, reviewing, and alerting | Provide evidence that a minimum of 30 days worth of security event logging data is immediately available, with 90 days of security event logs being retained. |
| Provide evidence that logs are being reviewed periodically and any potential security events/anomalies identified during the review process are investigated and addressed | |
| Provide evidence that alert rules are configured so that alerts are triggered for investigation for the following security events where applicable: privileged account creation/ modifications, privileged/high risk activities or operations, malware events, event log tampering, IDPS /WAF events. (if configured) | |
| Information risk management | Provide evidence that a ratified formal information security risk management policy/process is documented and established. |
| Provide evidence that a formal company-wide information security risk assessment is carried out at least annually. | |
| OR for Targeted Risk Analysis: a targeted risk analysis is documented and performed at a minimum of every 12 months for every instance where a traditional control or industry best practice is not in place, where a design/technological limitation creates a risk of introducing a vulnerability into the environment or puts users and data at risk, upon suspicion or confirmation of compromise. | |
| Validate that the information security risk assessment includes system component or resource affected, threats and vulnerabilities or equivalent, impact and likelihood matrices or equivalent, the creation of a risk register / risk treatment plan. | |
| Provide evidence that you have a risk management processes in place that assesses and manages risks associated with vendors and business partners and you can identify and assess changes and risks that could impact your system of internal controls. | |
| Security incident response | Provide your ratified security incident response plan/procedure (IRP). |
| Provide evidence outlining how your organization responds to incidents, showing how it is maintained, and that it includes details of the incident response team including contact information, an internal communication plan during the incident and external communication to relevant parties such as key stakeholders, payment brands and acquirers, regulatory bodies (for example 72 hours for GDPR), supervisory authorities, directors, customers as well as steps for activities such as incident classification, containment, mitigation, recovery and returning to normal business operations depending on the type of incident | |
| Provide evidence that all members of the incident response team have received annual training which enables them to respond to incidents. | |
| Provide evidence that the incident response strategy and supporting documentation is reviewed and updated based on either lessons learned from a table top exercise, lessons learned from responding to an incident, organizational changes. | |
| Business continuity plan and disaster recovery plan | Provide evidence that documentation exists, and is maintained, which outlines the Business Continuity plan. |
| Provide evidence the business continuity plan details relevant personnel and their roles and responsibilities including: business functions with associated contingency requirements and objectives, system and data backup procedures, configuration, and scheduling/retention, recovery priority and timeframe targets, a contingency plan detailing actions, steps, and procedures to be followed to return critical information systems, business functions, and services to operation in the event of an unexpected and unscheduled interruption, an established process that covers the eventual full system restoration and return to the original state. | |
| Provide evidence that documentation exists, is maintained, and outlines the disaster recovery plan and includes at a minimum: personnel and their roles, responsibilities, and escalation process, inventory of the information systems used to support critical business functions and services, system and data backup procedures and configuration, a recovery plan detailing actions and procedures to be followed to restore critical information systems and data to operation. | |
| Provide evidence that the business continuity plan and the disaster recovery plan are being reviewed at least every 12 months to ensure that it remains valid and effective during adverse situations. | |
| Provide evidence the business continuity plan is updated based on annual review of the plan, all relevant personnel receiving training on their roles and responsibilities assigned in the contingency plans, the plan/s are being tested through business continuity or disaster recovery exercises, test results are documented including lessons learned from the exercise 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. (TLS v1.2+ is recommended). 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 evidence that validates the TLS Configuration is TLS1.2 or higher within the TLS profile configuration requirements and that an inventory of trusted keys and certificates is kept and maintain. |
| Provide evidence shows TLS compression is disabled for all public facing services handling web requests to prevent Compression Ratio Info-leak Made Easy (CRIME), and TLS HSTS is enabled and configured to 180-days across all sites. | |
| Data at Rest | Provide evidence that data at rest is encrypted in line with the encryption profile requirements, using encryption algorithms such as Advanced Encryption Standard (AES), RSA and Twofish with encryption key sizes of 256-bit or higher. |
| Data Retention, back-up and disposal | Provide proof that an approved data retention period is formally established and documented. |
| Provide evidence that data is retained only for the defined retention period as discussed in previous control. | |
| Provide evidence that processes are in place to securely delete data after its retention period. | |
| Provide evidence that an automated backup system is in place and configured to perform backups at scheduled times. | |
| Provide evidence backup information is tested in line with the backup scheduling procedure and restored periodically to confirm the reliability and integrity of the data. | |
| Provide evidence appropriate access controls and protection mechanisms (i.e. immutable backups) are implemented to ensure backups / system snapshots are secured against unauthorized access and to ensure the confidentiality, integrity, and availability of the backup data. | |
| Data Access Management | Provide evidence that a list of users with access to data and/or encryption keys is maintained. Including the business justification for each person and confirmation this list of users was formally approved based on access privileges required for their job function and users are configured with the privileges outlined in the approval. |
| Provide evidence that a list of all third parties that data is shared with is maintained and data sharing agreements are in place with all third-parties consuming data. | |
| Privacy | Does your organization have a Privacy Information Management (PIM) system established, implemented, and maintained that holds leadership commitment by way of a policy or other form of documentation / computerized system for how your privacy information management efforts are maintained for system confidentiality and integrity. Determines roles, responsibilities and authorities of each person maintaining the system, including PII Processors and Controllers. |
| Provide evidence of processes to verify PII minimization is taking place, PII de-identification and deletion is being done at the end of the processing period, controls are in place for PII transmission including any confidentiality, record of transfer of PII from one country/region to another exists with expressed consent to do so. | |
| GDPR | Provide evidence that data subjects are able to raise SARs, that the ISV is able to identify all locations of data subjects' data when responding to a SARs request, that there is a retention period for backups which allows clients requesting removal of data via SAR's to be removed as rolling backups over a period are removed (lifecycle of oldest back up deletions/rewritten over). |
| Provide the privacy notice which should contain all the required elements as follows: oranizational details (name, address, and other personal identifiable information), the type of personal data being processed, how long personal data will be kept for, the lawfulness of processing personal data, data subjects rights; including: 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. | |
| HIPAA | Provide evidence that: a policy exists for HIPAA and HIPAA handling within your organization for staff, contractors, vendors, etc. Verify our organization ensures confidentiality, integrity, and availability of ePH. |
| Verify that you: provide protection against reasonably anticipated uses or disclosures of such information that are not permitted by the privacy rule, ensure compliance with the security rule by its workforce. Provide a data backup and disaster recovery plan under 164.308 (a)(7)(ii)(A) and 164.308 (a)(7)(ii)(B). |
Optional external compliance frameworks review
Although it isn't required, if you're currently in compliance with ISO 27001, PCI DSS, FedRAMP or SOC2, you can elect to use these certifications to satisfy some of the Microsoft 365 Certification controls.Analysts will try to align existing external security frameworks to the Microsoft 365 Certification framework. 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 security 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 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 framework. |
| FedRAMP | The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. federal government-wide program established in 2011. It provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. |
| 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 an app 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 in-scope 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.