Cloud security assessment checklist: 12 checks for Microsoft 365, Entra ID, Azure and AWS

TL;DR

• Twelve checks you can run in your own tenant or account, with a reader role, before you book an external cloud security assessment.
• Identity comes first: MFA gaps, standing admin rights, conditional access exclusions and forgotten app registrations do more damage than an open port.
• Storage, mail forwarding rules, logging and backups follow, because that is where assessors keep finding the same mistakes.
• A checklist shows whether a setting is on. An assessment shows whether the whole picture holds, and a cloud pentest shows what an attacker does with the gaps.

Many organisations in Belgium and the Netherlands with 20 to 500 people run on Microsoft 365, with Entra ID as the identity layer and a few Azure subscriptions or an AWS account beside it. That tenant rarely gets the attention the office network got. This checklist gives you twelve checks you can run yourself in an afternoon, in the admin portals you already have. It is the practical companion to our earlier post on what a cloud security assessment reviews, which explains each domain in more depth. If you would rather have someone else do the work, our cloud pentest covers the same ground and then tries to exploit what it finds, and the pentesting overview explains how an engagement runs.

How to use this checklist

Open the Entra admin center, the Microsoft Defender portal, the Azure portal and the AWS console with a role that can read but not change. Mark each check green, orange or red, and write down who owns the fix. You are not scoring yourself. You are making a list.

Identity and access

1. MFA on every account, with no legacy exceptions

Check that every user, including guests and admins, has MFA enforced, and that legacy authentication (IMAP, POP, SMTP AUTH, basic authentication) is blocked. In AWS, check that the root user has MFA and that no IAM user signs in with only a password.

2. Standing admin rights

Count the Global Administrators in Entra ID and the roles with AdministratorAccess in AWS. Anyone who holds those rights permanently, instead of activating them when needed through Privileged Identity Management or a role assumption, is a red item.

3. Conditional access policies and their exclusions

Read every policy, including the ones in report-only mode that were never switched on. The exclusion lists are where assessors find the service account that bypasses MFA because a migration needed it two years ago.

4. App registrations, service principals and access keys

List the app registrations that hold a secret or certificate, the ones nobody can name an owner for, and the Graph permissions they carry. In AWS, list the access keys older than the rotation period you say you follow.

5. Guest access and sharing

Check how guests get invited, what they can see in the directory, and which SharePoint and OneDrive sites allow anonymous links. One tenant-wide setting usually decides this, and it is often still the default.

Data, storage and mail

6. Public storage and long-lived SAS tokens

In Azure, look for storage accounts that still allow anonymous blob access and for SAS tokens without an expiry date. In AWS, confirm that Block Public Access is on at account level and that no bucket policy grants read to everyone.

7. Mail flow and forwarding rules

In Exchange Online, list the mailbox rules and transport rules that forward to external addresses, and check SPF, DKIM and DMARC on every domain that sends mail. A forwarding rule is the standard way an attacker keeps reading mail after you reset the password; our guide on business email compromise shows how that plays out.

Network exposure

8. Management ports and databases open to the internet

Search network security groups in Azure and security groups in AWS for rules that allow 0.0.0.0/0 on RDP, SSH or database ports, and list every public IP attached to a database or storage service. This is the one check where a scanner helps. The other eleven need a person reading settings.

Secrets

9. Where secrets live

Check whether connection strings and API keys sit in Key Vault or Secrets Manager, or in app settings, pipeline variables and repositories. Search your repositories for the obvious patterns and look at who can read the vault.

Logging, detection and recovery

10. Logs that are on and kept

Confirm that the Unified Audit Log is on in Microsoft 365, that Entra sign-in logs are kept longer than the default and sent to a workspace you can query, and that CloudTrail covers every AWS region. Nobody notices the intruder if the logs stop after a few days.

11. Backup and a tested restore

Check what Microsoft 365 retention really covers, whether Azure and AWS backups are immutable and stored in a separate account, and when you last restored something. A backup you never restored is a hypothesis.

Ownership and shared responsibility

12. Who owns the tenant

Write down who owns each subscription, each account and the tenant itself, who reviews access and when the last review happened. Secure Score in Microsoft 365 and Security Hub in AWS give you a starting baseline, but a score is not an owner.

What to fix first

Fix identity before anything else: standing admin rights, MFA gaps and the conditional access exclusions. Then close public storage and external forwarding rules, because those are the findings an attacker uses on day one. Logging and backups come third. They matter as much, but they limit damage rather than prevent entry.

Checklist done. Assessment, pentest or both?

The checklist tells you whether a setting is on. A cloud security assessment puts an outside pair of eyes on the whole configuration, including the parts you did not think to check; the earlier post describes what that covers. A cloud pentest goes one step further. It takes a low-privilege account and tries to reach administrator rights through the gaps, the way we describe in cloud IAM pentesting. For most organisations the assessment comes first, and the pentest follows once the obvious findings are fixed.

Frequently asked questions

Can I run this cloud security assessment checklist myself?

Yes. A reader role in each portal is enough for every check, and a single Microsoft 365 tenant with one or two subscriptions takes an afternoon. What you cannot do yourself is see what you did not know to look for, and that is the gap an external assessment closes.

Does the checklist cover Microsoft 365 or only Azure and AWS?

It covers all three, because the identity layer is shared: Entra ID authenticates your Microsoft 365 users and your Azure subscriptions. Checks 1 to 5 and 7 are mostly Microsoft 365 and Entra ID, checks 6, 8 and 9 apply to Azure and AWS, and the rest apply everywhere.

What should I do with the red items?

Group them by owner, fix the identity items first and record what you changed. If you then want the fixes verified, a cloud pentest tests whether the paths you closed are really closed, and the report gives you evidence for an auditor or an insurer.

Does Google Cloud fit this checklist?

Yes, with different names for the same checks: IAM and organisation policies for identity, public access prevention for Cloud Storage, Cloud Audit Logs for logging. It is not in the title because most tenants we see in Belgium and the Netherlands run Microsoft 365 with Azure or AWS beside it.

Is this checklist enough for NIS2 or ISO 27001?

No. NIS2 asks for risk management measures and for evidence that you review them, and ISO 27001 asks for a management system around the controls. The checklist is a good input for both; our NIS2 compliance page explains what auditors ask for in practice.

How does this relate to zero trust?

Checks 1 to 3 are the identity side of zero trust as NIST describes it in SP 800-207: verify every request, grant the least rights, assume the network is hostile. The checklist makes that concrete for one tenant; our post on zero trust security covers the model.

How often should I repeat the checklist?

Every quarter for the identity checks, and after every migration or new integration for the others. Settings drift because people solve problems under time pressure, and the checklist catches the exceptions that outlived the problem.

Related services and resources

Our cloud pentest for AWS, Azure and Google Cloud picks up where this checklist stops, and the cloud security solution page describes the full picture for organisations that want ongoing attention. For the reasoning behind each domain, read what a cloud security assessment reviews, and for the identity side in detail, cloud IAM pentesting. If stolen credentials are your main worry, the post on infostealers and stolen credentials explains how accounts get taken over in the first place, and how much does a pentest cost explains what determines a quote before you ask for one.