Integrations / Cloud & infrastructure
Screenata + Microsoft 365How do you continuously monitor Microsoft 365 for SOC 2, ISO 27001, and HIPAA?
Quick answer
Yes, you can run a SOC 2, ISO 27001, or HIPAA compliant operation on Microsoft 365, but Microsoft 365 itself is not the thing that gets audited. Microsoft certifies the service layer it operates and publishes its own attestation reports for it. Your tenant configuration, Conditional Access and MFA policies, external sharing limits, and retention settings are yours to get right and yours to evidence. Screenata runs 78 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Microsoft 365 through an app registration with read-only Graph permissions and runs 78 native checks against your tenant: Entra ID identity posture, Defender protection, and Exchange, SharePoint, and Teams security settings. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog, so one scan feeds every framework you run.
78 native checks · read-only · signed evidence
What it proves
Microsoft 365 evidence, mapped to controls.
MFA enforcement on users and administrators, and the tenant's authentication posture.
Proof that tenant access requires strong authentication, the first thing an auditor samples.
Defender protection settings across the tenant and whether malware defenses are enabled where expected.
Configuration snapshot showing malware protection in force on the scan date.
Exchange security settings, including how mail flow and external forwarding are governed.
Proof that mail handling follows the data transfer rules your policies describe.
SharePoint sharing posture, including how broadly content can be shared outside the organization.
Findings that document sharing is restricted to what the system description claims.
Teams security settings, including how external participation and access are governed.
Configuration snapshot showing collaboration boundaries in force on the scan date.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Microsoft 365, and why each matters.
All users have MFA enforced
Without a tenant-wide Conditional Access policy requiring MFA, a stolen or sprayed password grants single-factor access to Microsoft 365. An auditor verifies an enabled policy applies MFA to all users, not a report-only or scoped one.
Authentication method policy enables an MFA-capable method
If no MFA-capable method is enabled tenant-wide, users cannot register a second factor even when policy demands it. Auditors confirm at least one method such as Authenticator, FIDO2, or software OATH is enabled.
Admin users have MFA enforced
Privileged accounts are the highest-value target, so an admin reachable with a password alone risks tenant takeover. An auditor checks that an enabled Conditional Access policy requires MFA for administrator roles.
Admins must use phishing-resistant MFA
OTP and push factors can be defeated by adversary-in-the-middle phishing and MFA fatigue, which matters most on admin accounts. Auditors verify a policy requires phishing-resistant strength such as FIDO2 or certificate-based authentication for admins.
Legacy authentication blocked
Legacy protocols bypass Conditional Access and MFA entirely, so leaving them open undoes the MFA policy. An auditor confirms legacy authentication is blocked tenant-wide.
Device-code flow blocked by Conditional Access
The device-code flow is a common phishing vector because it lets an attacker complete sign-in on a victim's behalf. Auditors verify Conditional Access blocks device-code flow where it is not needed.
Admin portals are restricted by Conditional Access
Open access to the admin portals lets any compromised session attempt privileged changes. An auditor checks that Conditional Access restricts who can reach the Microsoft admin portals.
Sign-in risk policy enabled in Identity Protection
Risky sign-ins from unfamiliar locations or anonymized IPs go unchallenged without a sign-in risk policy. Auditors confirm Identity Protection is configured to act on increased sign-in risk.
User consent for apps is restricted
If any user can consent to third-party apps, a malicious app can harvest data through delegated permissions. An auditor verifies user consent is restricted so risky grants route through admin review.
Security Defaults Enabled
Security Defaults provide a baseline of MFA and legacy-auth blocking for tenants without custom Conditional Access. An auditor confirms either Security Defaults or an equivalent policy set is in force.
Entra Password Protection Configured
Without banned-password enforcement, users pick predictable passwords that spraying attacks defeat. Auditors verify Entra Password Protection is configured to reject weak and banned passwords.
Entra Smart Lockout Configured
Smart Lockout throttles repeated failed sign-ins so brute-force attempts are slowed without locking out legitimate users. An auditor confirms the lockout threshold and duration are set.
Privileged Users Have MFA
An administrator without MFA is the single most direct route to tenant compromise. Auditors verify every privileged user has multifactor authentication registered and required.
Entra User Inventory
Access reviews and termination testing depend on a complete, system-generated list of directory users. This check enumerates the Entra user population so auditors sample against an authoritative roster.
Break-glass accounts excluded from CA policies
If emergency access accounts are caught by a faulty Conditional Access policy, admins can be locked out during an incident. An auditor confirms break-glass accounts are deliberately excluded and separately protected.
No app registration holds unused privileged Graph permissions
An app registration carrying unused high-privilege Graph permissions is a standing target that widens the attack surface. Auditors verify privileged permissions are pared back to what each app actually uses.
SharePoint external sharing is bounded
Unbounded external sharing lets content leave the organization to anyone with a link. An auditor checks that SharePoint sharing is limited to the boundary the data handling policy describes.
M365 Sensitivity Labels Configured
Without sensitivity labels, confidential content is not classified and cannot be protected or tracked consistently. Auditors confirm labels are defined so data can be handled according to its classification.
Drawn from Screenata’s Microsoft 365 check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
Microsoft offers a Business Associate Agreement for Microsoft 365 covering the services it designates as in scope, available on eligible business and enterprise plans. Microsoft publishes its own SOC and ISO certifications for the service through the Service Trust Portal. The agreement does not cover how you run the tenant. MFA enforcement, external sharing boundaries, retention settings, and who holds admin roles are your configuration and your evidence. Confirm with Microsoft which plan and which services your own agreement covers before placing PHI in the tenant.
What access does Screenata need to Microsoft 365?
An app registration with read-only Microsoft Graph permissions that a tenant administrator approves. Screenata uses it for scheduled scans and never receives write access. You can review the requested permissions before consenting, and revoke the app at any time from your own admin center.
Is the Microsoft 365 integration enough for SOC 2?
It covers the productivity and identity slice: authentication, malware defense, and sharing evidence from your tenant. A full SOC 2 program also needs infrastructure, policy, HR, and vendor evidence, which come from your other connections and documents. About 70% of evidence across a typical program is collected automatically.
How often do the Microsoft 365 checks run?
On a schedule, with weekly scans as the default cadence. Each run produces fresh findings, and evidence freshness is tracked so anything approaching staleness gets flagged before an auditor sees it.
What happens when a Microsoft 365 check fails?
Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your tenant is changed by Screenata; the connection is read-only by construction.
What are the steps to implement SOC 2 with Microsoft 365?
First, connect the tenant through an app registration with read-only Microsoft Graph permissions, which an administrator approves and can revoke. Second, let the first scan run and establish a baseline of where the tenant stands against the SOC 2 control set, instead of guessing which controls are already met. Third, fix what fails, which in most tenants means enforcing MFA on all users through an enabled Conditional Access policy, requiring phishing-resistant MFA for admins, blocking legacy authentication, restricting user consent for third-party apps, and bounding SharePoint external sharing to what your data handling policy allows. Fourth, let the scheduled scans collect the passing results as signed, timestamped evidence, so you build a history over the observation window rather than a single snapshot. Fifth, hand the evidence package to an independent auditor. The audit itself is a separate engagement you contract with a CPA firm; Screenata produces the evidence, it does not issue the report.
Is Microsoft 365 HIPAA compliant?
No service is HIPAA compliant on its own, and Microsoft does not claim Microsoft 365 is. Microsoft will sign a BAA covering the services it designates as in scope on eligible business and enterprise plans, which makes those services usable for PHI. Compliance is a property of how you configure and operate the tenant on top of them. What makes the difference is strong authentication on every account, sharing and retention settings that match your policies, mailbox and admin audit logging, and evidence that those settings actually held over time rather than on the one day you looked.
Do auditors accept evidence Screenata collects from Microsoft 365?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Microsoft 365, you know your real posture.
Related: Azure · Azure DevOps · Google Workspace · Microsoft Teams