Direct answer: verify identity and emergency access first, then audit coverage, sharing, data controls, backup, and incident response. Do not close a checklist item because a setting exists. Close it only after a named owner captures the configuration, generates a test event, verifies the expected result, and records any exception.
This checklist is a risk-review starting point, not a universal secure configuration or substitute for Microsoft licensing review, threat modeling, or a tenant-specific assessment. Test changes with report-only modes and controlled accounts before broad enforcement.
Priority Control Table
| Priority | Decision and pass condition | Owner | Required evidence |
|---|---|---|---|
| 1. Emergency access | At least two monitored emergency accounts are usable, excluded only where necessary, and tested without weakening daily administration | Identity lead | Account inventory, alert test, access test |
| 2. Admin authentication | Privileged roles use dedicated accounts and approved phishing-resistant authentication where supported | Identity lead | Role export, authentication-method report |
| 3. Conditional Access | Legacy authentication and high-risk access paths are blocked after dependencies and rollback are tested | Identity lead | Report-only results, exception list, sign-in test |
| 4. Audit and alerts | Required events are retained long enough and each priority detection has produced a test alert | Security operations | License map, audit query, alert ticket |
| 5. Sharing and access | High-risk sites have owners, approved sharing settings, and reviewed broad access | Collaboration owner | Site report, owner response, exception |
| 6. Data controls | Labels and DLP rules are simulated, measured, and enforced only for approved outcomes | Information protection | Policy export, simulation metrics, test event |
| 7. Recovery | Required objects have successful backup evidence and a representative restore accepted by the data owner | Recovery owner | Job result, item errors, timed restore record |
Owner Fields
- Executive risk owner: [name/title]
- Microsoft 365 service owner: [name/title]
- Identity and Conditional Access owner: [name/title]
- Security monitoring owner: [name/title]
- Information protection owner: [name/title]
- Backup and recovery owner: [name/title]
- Change approver and rollback lead: [name/title]
Runbook 1: Identity and Privileged Access
- Export privileged Microsoft Entra role assignments. Separate eligible from active assignments, identify service dependencies, and confirm every assignment has an owner and expiry or review date.
- Use dedicated privileged identities for administration. Do not use arbitrary holder counts as a pass condition; minimize permanent Global Administrator assignments according to operational needs and emergency coverage.
- Require approved phishing-resistant methods for privileged access where the tenant, devices, and break-glass design support them. Microsoft documents built-in authentication strengths for Conditional Access. Keep emergency access separately designed and monitored.
- Inventory legacy authentication before blocking it. Use sign-in logs and a report-only policy, contact application owners, migrate or isolate dependencies, define rollback, then enforce. Follow Microsoft's legacy authentication policy guidance.
- Where licensed, configure Microsoft Entra Privileged Identity Management with justified activation, limited duration, notification, and periodic review. Test activation and emergency access after policy changes.
Runbook 2: Audit, Detection, and Response
Confirm the tenant's actual Purview Audit license and retention. Audit Standard generally retains records for 180 days. Audit Premium provides a default one-year policy for specified Exchange, SharePoint, OneDrive, and Microsoft Entra records generated by appropriately licensed users; other records can remain at 180 days, and longer retention has additional requirements. Use Microsoft's audit retention documentation rather than assuming that an E5 tenant gives every event one year.
- List incidents the organization must detect: privileged-role changes, authentication-method changes, risky sign-ins, inbox forwarding, external sharing, bulk deletion, retention-policy changes, and backup failure.
- Map each incident to its audit source, license, query, alert rule, ticket route, responder, and required retention.
- Generate a controlled test event. Confirm ingestion time, alert content, assignment, escalation, and closure evidence.
- Export or forward records when the approved investigation window exceeds native retention. Protect access to the destination and test retrieval.
Runbook 3: Sharing, Classification, and DLP
Use SharePoint and OneDrive reporting to identify broad access, guests, anonymous links, stale owners, and unique permissions. Do not impose a universal link-expiry value. Data owners should approve link type and duration based on collaboration need, sensitivity, and external-party lifecycle. Record exceptions and expiration.
Define sensitivity labels from handling outcomes. A label may apply protection when configured, and DLP can evaluate labels or content classifiers in supported locations. Neither control is complete by default. Simulate policies, sample false positives and false negatives, test user overrides and alerts, then enforce in stages. The DLP versus backup guide provides an outcome matrix, while the governance framework assigns business ownership.
Runbook 4: Backup and Recovery
- List required Exchange, SharePoint, OneDrive, and Teams object types. Include metadata, permissions, versions, and destination requirements where they matter.
- Record native recovery and independent backup coverage separately. A backup handler does not imply a restore handler or legal export.
- Review the administrative boundary, storage responsibilities, retention, deletion controls, monitoring, and operator access. Require implementation evidence for any immutability or air-gap claim.
- Run a representative restore from a known recovery point. Record elapsed time, changed identifiers or metadata, unsupported objects, and data-owner acceptance.
- Exercise a destructive-event scenario using the Microsoft 365 ransomware recovery runbook.
Evidence Checklist
- ☐ Privileged-role and authentication-method exports reviewed by the identity owner.
- ☐ Emergency-access sign-in and alert test completed after Conditional Access changes.
- ☐ Report-only results, dependency exceptions, approval, and rollback for legacy-authentication blocking.
- ☐ Audit license and retention matrix plus one successful query for every required event source.
- ☐ Test alerts routed to a named responder and incident queue.
- ☐ High-risk site permission reports and owner-approved remediation.
- ☐ Label and DLP simulations with sample quality measurements.
- ☐ Backup item errors reviewed and representative restores timed and accepted.
- ☐ Every exception has an owner, reason, compensating control, approver, and expiry.
Limitations and Decision Gate
North Brook Vault manages its backup infrastructure and storage but does not currently provide native Object Lock configuration or enforcement, universal Microsoft 365 object recovery, or a guaranteed RPO or recovery outcome. This checklist does not certify security or compliance.
Decision gate: mark a control complete only when the named owner can show current configuration, a successful test, retained evidence, and a reviewed exception path.