BLOG

By David Chernitzky, CEO, Armour Cybersecurity  ·  Serving Toronto and organizations across North America  ·  Last updated August 21, 2026

Key Takeaways

• M365 is almost always in scope for compliance audits, even when it is not explicitly called out in the audit scope. Email, document management, and collaboration tools that hold, process, or transmit data subject to the compliance framework are in scope by definition. An auditor reviewing SOC 2 access management controls will ask about MFA enforcement across the organization’s systems; M365 is a primary system. An auditor reviewing HIPAA technical safeguards will ask about access controls and audit controls for systems holding ePHI; if clinical staff use M365 for any communication about patients, M365 is in scope.

A single M365 hardening engagement produces evidence that simultaneously satisfies requirements across multiple frameworks. MFA enforcement satisfies access management requirements in SOC 2, ISO 27001, HIPAA, and PCI DSS. Audit logging satisfies monitoring and audit trail requirements across all four frameworks. DLP policies and sensitivity labels satisfy data protection requirements in all four. The compliance mapping document produced by the hardening engagement organizes this evidence against each framework’s specific control language, eliminating the need to reconstruct the mapping during each audit cycle from scratch.

• Framework requirements specify what must be achieved, not how to achieve it. SOC 2 CC6.1 requires that logical access security software and infrastructure protect information assets, but it does not specify which specific M365 settings implement that requirement. The auditor reviewing CC6.1 compliance will examine the M365 conditional access configuration, the MFA enforcement policies, and the external sharing settings as the technical implementation of the control. The documentation produced by the hardening engagement that describes each configured control and its security purpose is what connects the technical implementation to the framework requirement in a form the auditor can evaluate.
• Operating effectiveness evidence is distinct from implementation evidence. A compliance audit that evaluates operating effectiveness, specifically a SOC 2 Type II audit covering a twelve-month period, requires evidence that controls operated consistently throughout the audit period, not just that they were configured at one point in time. Access review records demonstrating that M365 account access was reviewed quarterly, audit log review evidence demonstrating that security alerts were investigated, and any changes to the M365 configuration documented with an explanation are the operating effectiveness evidence that the Type II audit requires beyond the configuration screenshots that demonstrate implementation.
• CIS Benchmarks for Microsoft 365 provide the most granular technical guidance for M365 hardening aligned to compliance requirements. The CIS Microsoft 365 Foundations Benchmark contains specific configuration recommendations for every M365 security control, mapped to CIS Controls and cross-referenced to NIST CSF and other frameworks. Armour Cybersecurity’s M365 hardening methodology is aligned to this benchmark, which means the hardening engagement produces a configuration that is verifiable against published standards rather than against proprietary internal criteria that auditors cannot independently evaluate.

Framework by Framework: What M365 Controls Satisfy

SOC 2

SOC 2 Trust Services Criteria address M365 through several control categories. CC6.1 requires logical access controls protecting information assets, satisfied by MFA enforcement, conditional access policies, and external sharing restrictions that limit unauthorized access to M365 content. CC6.2 requires authorization of new user access, satisfied by the provisioning process for M365 accounts and the access review process that confirms access remains appropriate. CC6.3 requires modification and revocation of access following the joiner-mover-leaver process, satisfied by the M365 account lifecycle management procedures. CC6.6 requires MFA for remote access, satisfied by the conditional access policies that enforce MFA for all M365 authentication.

CC7.2 requires monitoring for anomalous system activity, satisfied by the audit logging configuration, alert setup, and Microsoft Defender for Office 365 threat detection. CC7.3 requires evaluation of security events, satisfied by the incident response procedures for M365 security alerts. For SOC 2 Type II, the evidence package for M365 controls includes the Secure Score baseline and post-hardening comparison as a summary measurement, the configuration screenshots for each implemented control as implementation evidence, the audit log export demonstrating that logging has been active throughout the period, the alert configuration documentation, and the access review records demonstrating quarterly review of M365 account access. These artifacts are structured as standard deliverables of the Armour Cybersecurity M365 hardening engagement.

ISO 27001

ISO 27001:2022 Annex A maps to M365 controls across multiple control categories. A.5.15 (Access Control) and A.5.16 (Identity Management) are satisfied by the M365 account lifecycle management, MFA enforcement, and conditional access policies. A.5.17 (Authentication Information) is satisfied by the MFA configuration and the password policy enforced through Entra ID. A.8.5 (Secure Authentication) is satisfied by the conditional access policies that require MFA for all M365 authentication. A.8.11 (Data Masking) and A.8.12 (Data Leakage Prevention) are satisfied by the DLP policies and sensitivity labels configured across Exchange, SharePoint, and OneDrive.

A.8.15 (Logging) and A.8.16 (Monitoring Activities) are satisfied by the unified audit log configuration, log retention settings, and alert configuration. A.8.20 (Networks Security) and A.8.23 (Web Filtering) are partially satisfied by the Defender for Office 365 safe browsing and threat protection configuration. The ISO 27001 compliance mapping document produced by the hardening engagement maps each Annex A control to the specific M365 configuration that implements it, with references to the configuration guide sections where the technical implementation is documented. For organizations seeking ISO 27001 certification, the M365 hardening engagement can be scoped to prioritize the controls that the certification assessor will examine in the surveillance audit, reducing the preparation work required before assessment.

HIPAA

HIPAA Security Rule requirements that M365 controls address include 45 CFR 164.312(a)(1) Access Control, which requires unique user identification (no shared M365 accounts), emergency access procedures, automatic logoff, and encryption. Unique user identification is enforced through the M365 account provisioning process. Automatic logoff is configured through session timeout settings in Entra ID. Encryption of ePHI in transit and at rest is provided by M365’s baseline encryption for email in transit and SharePoint and OneDrive content at rest, supplemented by Microsoft Purview Message Encryption for email containing ePHI that requires additional protection.

45 CFR 164.312(b) Audit Controls requires activity logging for systems that handle ePHI. The unified audit log in M365 captures email access, file access, sharing events, and administrative actions across the M365 environment. For HIPAA purposes, the audit log must be enabled, the retention period must be sufficient to meet the HIPAA record retention standard, and the log must be reviewed on a defined schedule. The audit logging configuration implemented in the M365 hardening engagement satisfies the technical requirement; the log review procedure and retention policy document satisfy the administrative safeguard requirement. For covered entities and business associates whose staff use M365 to communicate about patients, this configuration is a prerequisite for HIPAA compliance rather than an enhancement.

PCI DSS

PCI DSS v4.0.1 applies to M365 when the cardholder data environment includes systems or communications that flow through M365. Requirement 7 (Restrict Access to Cardholder Data) maps to M365 access controls: MFA enforcement, conditional access policies that restrict access to systems handling cardholder data, and DLP policies that detect and block cardholder data from being transmitted through email or SharePoint to unauthorized recipients. Requirement 8 (Identify and Authenticate Access) maps to the MFA configuration, the unique user identification requirement, and the session management configuration in Entra ID.

Requirement 10 (Log and Monitor All Access) maps to the unified audit log configuration, alert setup, and log retention. PCI DSS requires that audit logs be retained for at least twelve months, with the most recent three months immediately available for analysis. The M365 audit log retention configured in the hardening engagement must be set to meet this retention standard, and the alert configuration must surface events relevant to cardholder data access in a timely manner. The Secure Score measurement, the configuration guide, and the compliance mapping document produced by the hardening engagement are structured to align with PCI DSS Requirements 7, 8, and 10 so that the evidence package can be provided directly to a Qualified Security Assessor during a M365 hardening for compliance engagement.

Across the 260+ organizations Armour Cybersecurity protects in 52+ industries, the audits that stall on the M365 controls almost never stall because a control was missing. They stall because the control was in place but no one could produce the evidence that connected it to the requirement, which is exactly the gap a compliance mapping built during hardening closes before the assessor ever asks.

Frequently Asked Questions

Does M365 hardening satisfy all the requirements for SOC 2 certification?

No. SOC 2 certification requires controls across all five Trust Services Criteria, many of which extend well beyond the M365 platform to encompass organizational policies, HR security controls, physical security, availability and backup procedures, and the full scope of systems handling the in-scope data. M365 hardening satisfies the M365-specific controls within the access management, change management, and monitoring criteria and produces the evidence that the auditor needs to evaluate those specific controls. It does not replace the organizational policies, risk assessments, vendor management procedures, or non-M365 system controls that the audit also evaluates. For organizations pursuing SOC 2, M365 hardening is a significant and necessary component of audit preparation, not the entirety of it.

What does the compliance mapping document actually look like?

The compliance mapping document is a structured reference that lists each M365 control implemented during the hardening engagement alongside the specific framework requirements it satisfies. For each control, the document identifies the control name, the M365 configuration location, the implemented setting, and the framework requirements addressed, listed by framework and control ID. For example, MFA enforcement is listed with references to SOC 2 CC6.6, ISO 27001 A.8.5, HIPAA 45 CFR 164.312(d), and PCI DSS Requirement 8.3. The document is formatted for direct use during audit fieldwork: the assessor can use it to identify which controls satisfy which requirements and then request the configuration screenshots or audit log evidence for the specific controls under review.

What happens if our M365 configuration changes after the hardening engagement?

Configuration changes after the hardening engagement may affect compliance by modifying controls that satisfy framework requirements. This is why the post-hardening baseline documentation and the change management process are important components of the engagement deliverables. Any change to M365 security configuration, whether for troubleshooting, a new business requirement, or a platform update, should be reviewed against the compliance mapping to identify which framework requirements are affected and documented with a business justification. For SOC 2 Type II and similar continuous-effectiveness audits, undocumented changes to security controls are findings. A change management process that requires security review and documentation for M365 configuration changes protects the compliance posture established by the hardening engagement and makes the configuration change evidence available for the audit period.

How does M365 hardening interact with our existing compliance program?

M365 hardening fits into the broader compliance program as the technical control layer for the M365 environment. The compliance program provides the policies, risk assessment, and governance framework; the M365 hardening engagement implements the technical controls that operationalize those policies within the M365 platform. If the compliance program has already identified specific M365 control requirements from a prior audit or assessment, the hardening engagement is scoped to address those specific requirements in addition to the baseline hardening across all M365 surfaces. The compliance mapping produced by the engagement connects the technical implementation back to the compliance program’s control framework, ensuring that the evidence is organized in a way that the existing compliance documentation structure can absorb rather than creating a parallel evidence archive that must be manually cross-referenced at audit time.

The Bottom Line

Microsoft 365 sits inside the scope of nearly every audit an organization faces, and the controls auditors examine there, MFA and least privilege, DLP and sensitivity labels, audit logging and retention, are the same controls a proper hardening engagement implements. That overlap is the opportunity: hardened once with compliance in mind, a single M365 configuration produces evidence that satisfies SOC 2, ISO 27001, HIPAA, and PCI DSS at the same time, and a compliance mapping turns that evidence into something an assessor can use directly instead of something your team reconstructs before every audit. Hardening does not replace the rest of a compliance program, but it removes the M365 portion as a recurring source of findings. Armour Cybersecurity’s M365 hardening for compliance delivers the hardened configuration, the CIS-aligned baseline, and the framework-mapped evidence package as standard outputs, so the M365 layer of your next audit is prepared before fieldwork begins.