SPF, DKIM and DMARC help prevent attackers sending email that falsely claims to come from your business. SPF identifies authorised sending infrastructure, DKIM verifies a cryptographic signature, and DMARC connects those checks to the visible sender address and requests how failed messages should be handled. Publishing the records alone is insufficient: alignment and enforcement determine whether DMARC protects the visible sender identity against direct spoofing. These controls also leave gaps, including messages sent through compromised accounts, so start with what each protocol proves. Key Takeaways SPF checks whether the sending server is authorised for the envelope sender, DKIM verifies a signature on message content, and DMARC connects those results to the visible From address. DMARC passes when at least one of SPF or DKIM passes and aligns with the visible From address. Its policy applies to messages that fail DMARC, so p=none provides reporting visibility but doesn’t request enforcement. Inventory every legitimate sending service, publish the records through the authoritative DNS provider, and test each sending route before tightening DMARC. Keep a single SPF policy for the domain. SPF, DKIM and DMARC reduce direct spoofing of protected domains, but they don’t stop lookalike addresses or fraudulent email sent through a compromised account. Account security and payment verification remain necessary. What SPF, DKIM and DMARC actually check These are email authentication standards configured through DNS, rather than interchangeable security filters. Each supplies different evidence about a message, and none establishes that its contents or payment instructions are trustworthy. SPF identifies authorised sending infrastructure Sender Policy Framework (SPF) lists the servers and IP addresses authorised to send for an organisation. Receiving servers compare the connecting server’s IP address against its SPF policy. The important distinction is which address SPF checks. It normally evaluates the envelope sender address, associated with the Return-Path, rather than the address displayed in Outlook’s From field. An SPF pass therefore doesn’t, by itself, prove that the visible sender is genuine. That distinction matters when assessing business email compromise, where a familiar-looking sender can influence payment decisions. DKIM verifies a signature over message content DomainKeys Identified Mail (DKIM) uses a private key held by the sending service to sign selected headers and message content. The receiving server retrieves the corresponding public key through the supplied configuration. Successful verification shows that the signed content hasn’t changed since signing and links it to the identity in the DKIM record. It doesn’t establish that the sender’s account is uncompromised. Mail providers normally generate and manage the key pair. Publish their supplied records; never publish the private key. How DMARC alignment prevents direct domain spoofing Domain-based Message Authentication, Reporting and Conformance (DMARC) connects authentication results to the address shown in the visible From field. It also publishes handling instructions and lets owners request authentication summaries. A passing check must also align DMARC passes when at least 1 authentication method both passes and aligns: SPF or DKIM. A failed SPF check doesn’t automatically mean DMARC fails if aligned DKIM succeeds. Under default relaxed alignment, the authenticated identifier and visible From address can belong to the same organisation. Strict alignment requires an exact match. A marketing service can pass SPF using its own identifier yet fail DMARC for your visible address. Configuring DKIM to use the name in your From address can provide the required alignment. The policy determines the requested handling DMARC policies apply to messages that fail DMARC, not every message that fails either underlying check. Policy Requested handling Practical use p=none No DMARC-specific enforcement action Observe authentication results p=quarantine Treat failing messages as suspicious, commonly placing them in spam Introduce enforcement p=reject Reject failing messages Block direct domain spoofing Receiving services retain discretion and apply their own security policies. A monitoring policy doesn’t disable their spam filters, but it doesn’t request spoofing enforcement either. A published DMARC record with p=none provides visibility, not an instruction to block impersonation. Why Google and Yahoo require all 3 Google and Yahoo began introducing stronger bulk-sender authentication requirements in February 2024. Bulk senders need SPF, DKIM and DMARC, with at least a monitoring policy and the alignment needed for DMARC to pass. Google’s sender guidelines introduced the requirements on 1 February 2024 for senders exceeding 5,000 daily messages to personal Gmail accounts. Yahoo’s sender requirements also require bulk senders to authenticate with both SPF and DKIM and pass DMARC. These requirements address forged identities and unauthenticated traffic. They don’t guarantee inbox placement. Treat authentication as one item on a deliverability checklist alongside sending reputation, complaint rates, unsubscribe requirements and recipient consent. A technically authenticated cold email campaign can still be filtered or rejected. Smaller senders also benefit from protection, even where a bulk-sender threshold doesn’t apply. Identify the DNS host and every sending service Authentication records belong in the authoritative service for the sending domain. The registrar, a separate provider or a managed IT provider may operate it, rather than the company hosting email. DNS records have different roles MX records tell other systems where to deliver incoming email. SPF, DKIM and DMARC support authentication; changing MX records does not configure them. SPF and DMARC policies are published as TXT records. DKIM public keys are normally available through TXT records, but some providers use CNAME records that point to provider-managed keys. Microsoft 365 uses this approach. Inventory senders before changing policy Identify every legitimate sender before starting the authentication setup. Check Exchange Online, CRM platforms, marketing systems, payroll tools, ticketing systems, website forms and devices that send email. Record each service’s From address, envelope sender and DKIM signing identity. Missing a legitimate source can turn a sensible security change into a delivery failure. Include occasional senders, such as annual renewal notices, rather than relying on a single day’s traffic. An Office 365 assessment can place authentication alongside mailbox forwarding, permissions and other email security settings. How to configure SPF, DKIM and DMARC in Microsoft 365 Use this setup for each custom sending domain. Adding it to Microsoft 365 doesn’t complete authentication. The practical sequence is
How attackers hide Microsoft 365 forwarding rules
Attackers hide Microsoft 365 forwarding rules with misleading names, by targeting selected messages, or by creating rules that don’t appear in the standard rules list. After compromising an account, they can copy correspondence externally while moving or deleting messages that might expose the activity. A password reset doesn’t remove these rules. Effective recovery requires checking inbox rules, mailbox forwarding, mail flow rules and account access separately. Key takeaways Review forwarding at every level, not just the settings visible in Outlook. Preserve rule details and audit evidence before removing unauthorised changes. Block unapproved forwarding outside the organisation, but investigate how the attacker gained access and what information they accessed. How attackers conceal Microsoft 365 forwarding rules Ordinary rules can be difficult to notice A malicious rule does not need advanced concealment to remain unnoticed. An uninformative name, narrow matching conditions or placement amongst existing rules can delay discovery. Rules may target invoices, payment discussions or messages from particular suppliers rather than forwarding everything. Other actions can move matching messages into rarely reviewed folders, mark them as read or delete them. This can support business email compromise, where an attacker monitors genuine correspondence before impersonating a participant or changing payment instructions. The mailbox may otherwise appear to work normally. Stolen credentials are one route into an account, although stolen sessions and malicious application permissions also matter. Our guidance on leaked employee passwords explains why exposure requires investigation beyond changing a password. Hidden rules require an administrative view Some rules are hidden from the standard rules interface. A clean-looking rules list therefore does not establish that the mailbox is safe. Administrators can inspect hidden inbox rules through Exchange Online PowerShell using the IncludeHidden parameter. This is a separate check from reviewing the forwarding address configured directly on the mailbox. Rule names are weak evidence either way. Review the conditions, actions, destinations and creation history, then establish whether the business authorised them. Where to inspect forwarding and mailbox changes Review all forwarding locations Microsoft 365 has several mechanisms that can send messages elsewhere. Checking only the user’s client settings leaves gaps. Use the following comparison to structure the review. Mechanism Where to inspect What to establish Inbox rules User-facing mail client and Exchange Online PowerShell Forwarding, redirection, deletion and folder actions Hidden inbox rules PowerShell with IncludeHidden Rules absent from the normal client list Mailbox forwarding Microsoft 365 admin centre or Exchange administration Destination and whether the source retains messages Organisation-wide transport rules Exchange admin centre, Mail flow, Rules Organisation-level conditions, recipients and actions An unexpected destination warrants investigation, but an internal address can also belong to another compromised account. Include shared mailboxes in the scope. Their access permissions and ownership require separate attention, as explained in our shared mailbox security guidance. Use PowerShell alongside audit records With authorised Exchange Online permissions, run Get-InboxRule -Mailbox $mailbox -IncludeHidden, where $mailbox contains the affected mailbox identity. Examine forwarding destinations, redirection, deletion, folder movement, priority and whether a rule stops subsequent processing. Also inspect ForwardingAddress, ForwardingSmtpAddress and DeliverToMailboxAndForward through Get-Mailbox. Search Microsoft Purview audit records for relevant rule and mailbox changes. Events can include New-InboxRule, Set-InboxRule, UpdateInboxRules and Set-Mailbox, depending on how the change occurred. Correlate timestamps with Microsoft Entra sign-ins, application permissions and administrator activity. Available history depends on audit configuration, retention and licensing. Contain the account without losing evidence Preserve the configuration and establish exposure Record the rule identity, conditions, actions, destination, mailbox and relevant timestamps before removal. Export available audit records and retain suspicious message headers. Containment should not wait for a complete investigation, but deleting every suspicious item immediately can remove useful evidence. Establish which messages matched the rule, whether forwarding succeeded and whether attachments contained personal or confidential information. A configured rule shows intent; it does not prove that every matching message reached its destination. Review payment-related conversations for altered bank details or impersonation. Where fraud is suspected, involve the finance team and contact the bank promptly. Remove persistence as well as access Block sign-in where appropriate, revoke sessions and reset the account credentials. Session revocation does not guarantee that every existing access token stops working instantly. Remove unauthorised rules and forwarding settings after preserving evidence. Review delegates, application consent, authentication methods and privileged access as well. A password reset alone leaves configuration-based persistence untouched. Similarly, deleting a forwarding rule does not remove the access that allowed its creation. Our Microsoft 365 security assessment can help identify configuration and access weaknesses. For ongoing managed detection and response, establish which identity, email and cloud events are monitored and who can authorise containment. Why external forwarding is blocked Microsoft 365 normally blocks automatic external email forwarding by default. Existing policies and exceptions affect the effective configuration, so a forwarding address alone doesn’t prove that messages are leaving the organisation. The rejection can read: Remote Server returned 550 5.7.520 Access denied, Your organization does not allow external forwarding Microsoft’s external forwarding guidance explains how outbound spam policies restrict inbox-rule and administrator-configured mailbox forwarding to external addresses. Internal forwarding is treated differently. In Microsoft Defender, open Email & collaboration, Policies & rules, Threat policies, then Anti-spam. Select the outbound policy and choose Edit protection settings. Under Forwarding rules, inspect Automatic forwarding rules. Choose the explicit Off setting to disable automatic forwarding when messages must not be sent outside the organisation, rather than relying on the system-controlled option. A blocked forwarding attempt doesn’t prove that the mailbox was protected throughout. The attacker may already have read messages directly, downloaded attachments or accessed another mailbox. Review the rule’s lifetime and available activity records before determining the incident’s scope. Troubleshoot approved forwarding without weakening protection Start with the rejection message and the policy applied to the source mailbox. Check the label in older Office 365 accounts or runbooks before changing settings. Policy scope, priority and other mail-flow restrictions can explain why an enabled setting still fails. For an authorised exception, enable external email forwarding by setting the outbound policy’s Automatic forwarding rules option to On – Forwarding is
Microsoft 365 BYOD: safe access on personal phones
Staff can access Microsoft 365 safely on personal phones when access is limited to protected apps, strong authentication and enforceable device standards. Multi-factor authentication (MFA) alone doesn’t control where attachments are saved, whether a phone receives updates or what happens to work data after someone leaves. A practical BYOD policy sets a clear data protection boundary for personal devices, separating organisational information from personal content without requiring the business to manage the entire phone. Start by deciding which access requires app protection and which requires a company-managed device. Key takeaways Personal phones can often use Outlook, Teams and OneDrive through Intune app protection without full device enrolment. More sensitive access may justify enrolment, device compliance or company-owned hardware. Conditional Access must enforce those decisions. A written policy, an installed app or an assigned licence does not demonstrate that access restrictions work. What Microsoft 365 BYOD controls can enforce Conditional Access in Microsoft Entra ID (formerly Azure AD) decides whether access is permitted. Intune applies app-level protection or manages enrolled devices, whilst Defender for Endpoint can contribute device-risk signals. These controls address different problems. Requirement Microsoft control Important limit Stronger sign-in Entra Conditional Access and MFA Authentication does not contain downloaded data Protect work information inside apps Intune app protection Only supported apps and platforms receive protection Require acceptable device settings Intune compliance with Conditional Access Enrolment and platform support affect available checks Block risky devices Defender for Endpoint integration Requires deployment, configuration and suitable licensing Restrict unmanaged downloads Defender for Cloud Apps session controls Applies to supported browser sessions The decision is whether the organisation needs control over work data, the device, or both. App protection without device enrolment Mobile application management (MAM) protects organisational information inside supported apps. Intune app protection policies can require an app PIN, restrict copying into personal apps and limit saving to personal storage. These controls do not provide unrestricted visibility into the phone. They also cannot guarantee that someone will not photograph information displayed on its screen. Device compliance adds a separate test Mobile device management (MDM) enrolment supports broader device controls. Compliance policies can assess operating system versions, passcodes, encryption and root or jailbreak status, depending on the platform. Windows compliance can also assess Microsoft Defender Antimalware. Intune compliance status becomes an access restriction when Conditional Access requires a compliant device. Configure access for personal phones Configure protection before requiring it. Otherwise, staff may encounter blocked access without an available route to meet the policy. Require protected mobile apps For ordinary mobile email and collaboration, establish an iOS/iPadOS and Android app-protection baseline, then enforce it through Conditional Access. Assign Intune app protection to the intended users and supported work apps. Configure Conditional Access for those users, Microsoft 365 resources and mobile platforms, requiring MFA and an app protection policy. Test in report-only mode, review sign-in results, then enable enforcement for a pilot group. Microsoft’s approved-client-app migration guidance describes the 30 June 2026 retirement change: existing enabled policies remain enforced but become read-only. Move suitable mobile policies to app-protection-based enforcement. The approved-client-app and app-protection grants discussed here apply to iOS/iPadOS and Android, not equivalent Windows or macOS enforcement. For staff setup, our guidance on Microsoft 365 email on iPhones covers the account configuration. Restrict unmanaged browser sessions Where unmanaged access is permitted, block desktop and mobile clients that would bypass the intended browser restriction. Route supported browser sessions through Conditional Access App Control, then apply a Defender for Cloud Apps session policy blocking downloads. This requires Defender for Cloud Apps and Entra ID P1 licensing. It reduces local file storage but cannot prevent every form of information capture. Keep personal phones separate from personal computers A mobile app-protection decision should not automatically authorise unrestricted access from personal Windows or macOS computers. Windows ownership is not a security assessment Windows devices enrolled through Company Portal or by adding a work account are ordinarily classified as personal. Autopilot enrolment, including supported Microsoft Entra joined and hybrid joined deployments, is classified as corporate-owned. Neither label proves that the device meets policy. Device ownership classification and compliance serve different purposes. Windows has limited Edge app-protection capabilities, but these aren’t equivalent to containing every desktop application. Windows Information Protection is deprecated and shouldn’t form the basis of a new BYOD design. Limiting local admin privileges restricts privileged software installation, although some user-level applications remain possible. If that restriction is impractical on an employee’s computer, provide managed equipment. Contractors need a workable access route A personal phone generally can’t hold separate corporate MDM enrolments for several organisations simultaneously. Contractors already managed by another business may encounter enrolment conflicts. Supported app protection or restricted browser access may avoid a second enrolment, but account switching and tenant-specific restrictions need testing. With Bring Your Own PC (BYOPC), Windows 365 offers another route for staff using their own hardware. Microsoft positions BYOPC for flexible workers, temporary and seasonal staff, contractors, students and interns. Clipboard, drive and download redirection still need controls. Copy-ready BYOD policy clauses Use this security policy template as a baseline, then identify the responsible team and approved data categories before adoption. Each requirement needs a corresponding configuration or operational process. Personal-device access is permitted only for authorised staff, approved applications and assigned business purposes. Restricted information and privileged administration require company-managed equipment unless an exception is documented. Work accounts must use MFA. Privileged roles must use phishing-resistant authentication where supported, with separate administrative accounts rather than routine email accounts. Supported phones must receive security updates, use a passcode and automatic locking, and meet the configured minimum operating system version. Rooted or jailbroken devices are prohibited. Work information must remain within approved apps and storage. Staff must not copy protected information into personal email, consumer cloud storage or unapproved AI applications. IT may assess defined device and app security information, restrict access and remove managed work data. A staff notice must explain privacy and monitoring, including what IT can see and which remote actions it may take. Lost or stolen devices
Restore a deleted SharePoint file without losing edits
To restore deleted SharePoint file content without overwriting newer edits, first preserve any newer copies. Use a single-item restore where possible, rather than rolling back an entire document library and reversing unrelated work. The recovered file contains the content and retained versions available when it was deleted, not changes subsequently saved elsewhere. Start by separating the missing document from any newer copies before choosing a recovery method. Key Takeaways Preserve newer or unsynchronised copies before restoring a deleted SharePoint file, then compare them with the recovered document and merge any required edits. Restore a selected item from the first-stage Recycle Bin where possible. The second-stage Recycle Bin requires site collection administrator access, and both stages share the same 93-day recovery period from the original deletion. Use Version history when a file still exists but was overwritten. Reserve Restore this library for wider damage because it can reverse legitimate activity from the previous 30 days. For bulk recovery, use PnP PowerShell with a defined scope, recorded item IDs and batches below 5,000 items. Check the inventory and filters before rerunning a command that restores nothing. If an item has been permanently removed from the second-stage bin, raise a Microsoft Support request promptly or check whether a separate backup can restore it to an alternate location. Protect newer edits before starting recovery Preserve the current working copies Identify the original SharePoint site, document library, folder and filename. Then establish whether somebody has recreated the document, saved a replacement or continued editing a locally synchronised copy. Ask affected users to stop editing temporarily. Save newer content separately, using a different filename or recovery folder, before attempting restoration. If a device contains unsynchronised changes, preserve those locally before reconnecting it. A downloaded copy protects the document’s content, but does not preserve its complete SharePoint version history, permissions or metadata. Record those separately where they matter. Keep the recovery scope narrow Recover the deleted item rather than restoring the whole library when only that item is missing. A wider rollback can reverse legitimate changes made after the selected recovery point. If the original path already contains a same-name file, preserve that newer document before resolving the conflict. Do not delete it simply to make the restore succeed. After recovery, compare the recovered file with the preserved working copy and merge the required changes. For Word documents, Review > Compare can help identify differences. Record which copy becomes authoritative before colleagues resume editing. Restore the file from the first-stage Recycle Bin The SharePoint recycle bin is the normal starting point. Restoring a selected item returns it to its original location, subject to any conflict or error that needs attention. Follow These Steps: Open the SharePoint site containing the deleted document. Select Recycle Bin in the left-hand navigation. If it’s absent, open the Settings gear icon, select Site Contents and find Recycle Bin. Identify the correct item using its name, original location, deletion date and deleted-by details. Select the item, then choose Restore. Open the recovered document and review its content and version history before releasing it for normal use. Navigation labels vary between SharePoint experiences. Microsoft’s SharePoint and Teams recovery instructions describe the supported route. If the file is absent, ask a site administrator to investigate. An empty personal view doesn’t establish that everybody’s deleted items have disappeared. Escalate to the second-stage Recycle Bin The second-stage Recycle Bin, also called the site collection Recycle Bin, holds items removed from the first stage for the remaining recovery period. Restoring items from this stage requires site collection administrator permissions. Open the site’s Recycle Bin and follow the second-stage Recycle Bin link at the bottom of the page. An authorised administrator can identify the item, select it and choose Restore. Microsoft’s site collection recovery guidance confirms that restored items return to their original locations. Moving an item into this stage does not create another recovery window. An item deleted from its original folder 90 days ago normally has only 3 days remaining, even if it entered the second-stage bin today. If an item is missing from your view, ask the Microsoft 365 administrator to investigate. You may still be able to recover deleted files at this later stage, depending on how much of the original recovery window remains. Understand the 93-day SharePoint recovery window These recovery options have different limits. Recovery option Available window Effect on newer work First-stage Recycle Bin Within the shared 93-day period Restores selected deleted items Second-stage Recycle Bin Remainder of the same 93 days Restores selected items with administrator access Restore this library Previous 30 days Reverses library activity after the chosen point Separate backup Configured backup retention Depends on restore scope and destination The narrowest suitable option normally creates the least disruption. The clock starts at the original deletion SharePoint Online normally retains deleted items for 93 days after deletion from their original location. Microsoft’s SharePoint retention documentation confirms that the 93-day retention period spans both Recycle Bin stages. Do not apply general 14-day or 30-day recycle-bin advice to SharePoint Online. Nor is its standard 93-day period simply an administrator-selectable shorter setting. SharePoint Server has different configuration rules. Some items disappear before 93 days An administrator can permanently remove items from the second-stage bin. SharePoint also purges its oldest items if that bin exceeds its allocation. First-stage storage counts towards the site quota. The second-stage allocation is 200% of the site collection quota, rather than a universal 25GB allowance. Neither bin is independent backup storage. Distinguish version history from library rollback Use version history for an existing document If the file still exists but its contents were overwritten, start with Version history rather than the Recycle Bin. Review the saved versions and identify the required content. Restoring an older version makes it current; it does not automatically merge that content with newer edits. Preserve the current content first, then compare or combine the versions. Version history is part of sound SharePoint document management, but its usefulness depends on the versions still being
Microsoft 365 sign-in logs: why locations look wrong
Microsoft 365 sign-in logs show unfamiliar locations because Microsoft normally estimates location from the connection’s public IP address, not the user’s physical position. VPNs, mobile networks and security proxies can explain unexpected countries or cities, but compromised accounts can produce similar records. Treat location as supporting evidence, rather than proof that a sign-in is legitimate or malicious. Start with the connection details, authentication result and surrounding activity before deciding whether to dismiss the event or contain an incident. Key Takeaways Microsoft 365 sign-in locations are estimates based on public IP addresses, not a user’s physical position. VPNs, proxies, mobile networks and inaccurate geolocation data can explain unfamiliar places. Assess an event using its IP address, timestamp, application, device, authentication details and Conditional Access result. Correlate nearby sign-ins with employee activity and changes to mailboxes, applications, files and permissions. When evidence supports account compromise, block sign-in, revoke sessions and reset credentials. Review other access routes separately, since a password reset doesn’t remove every route an attacker may have established. Entra log retention depends on the licence, and expired records can’t be recovered by upgrading. Download records before expiry or configure diagnostic settings to send selected categories to a longer-term destination. Why Microsoft 365 sign-in logs show unexpected places In Microsoft 365 logs, an authentication event’s location is based on the connection’s public IP address. It doesn’t show the user’s physical position, and an unfamiliar location alone isn’t evidence of compromise. VPNs, proxies and mobile networks A corporate VPN can route traffic through another office or country. Cloud security proxies can also present an outbound IP address belonging to the security provider rather than the employee’s internet connection. Mobile networks commonly use shared infrastructure, so the reported city may differ substantially from the handset’s location. Compare the recorded IP with known corporate exit addresses and the connection used at that time. Microsoft’s Conditional Access network guidance explains how network location informs access decisions. IP geolocation and background authentication IP geolocation databases are estimates. Address reassignment, internet provider routing and incomplete registration information can produce inaccurate results, particularly at city level. Also distinguish interactive sign-ins from non-interactive activity. Outlook, Teams and other applications can request tokens without the user entering a password again. Several records do not necessarily mean several manual logins, and an unfamiliar background event still requires context before it can be classified. Investigate the event before dismissing it Assess an unfamiliar location against the IP address, timestamp, application, device, authentication details and Conditional Access result. A successful sign-in deserves more attention than a blocked attempt, but neither the location nor the status alone establishes whether an account has been compromised. Establish what the record shows In the Entra Admin Center, open Entra ID, then Monitoring & health, then Sign-in logs. Reports Reader is the least-privileged role for viewing Microsoft Entra activity logs. Review the failure reason or success status, client application, resource, device information and authentication sequence. Compare timestamps using the displayed time zone and retain the event identifier. A successful multifactor authentication (MFA) result doesn’t prove that the account owner intended the access. Authentication may rely on an existing claim, and attackers can obtain access through techniques such as Microsoft 365 device-code phishing. Correlate identity and workload activity Compare the event with nearby sign-ins, known travel, VPN records and the employee’s device activity. Contact the employee through an established channel rather than relying on the potentially compromised mailbox. Then examine mailbox forwarding, inbox rules, application consent, file access and permission changes. An attacker using an authorised application may cause little obvious disruption to sign-in activity. An unexpected location label isn’t itself a risky sign-in or an Entra ID Protection risk detection. These detections consider additional signals, and their absence doesn’t prove the activity is safe. Contain confirmed or strongly suspected compromise Block sign-in, revoke sessions and reset compromised credentials when the evidence supports account takeover. Preserve relevant records, but do not delay containment while preparing a complete export. Session revocation invalidates refresh tokens, but existing access tokens can remain usable until expiry or another enforcement mechanism intervenes. Continuous Access Evaluation can shorten that window for supported services. Blocking the account does not guarantee that every session ends immediately. Review forwarding rules, inbox rules, connected applications, authentication methods and privileged assignments separately. A password reset does not automatically remove every route an attacker may have established. The same distinction matters when an unfamiliar event involves a former employee. Our Microsoft 365 leaver checklist separates live-access removal from permissions and data cleanup. Document the affected account, evidence, containment actions and investigation owner. A familiar location should not override evidence of unauthorised activity elsewhere. How long Microsoft Entra keeps the evidence Default retention depends on the underlying Entra licence, not simply whether the business uses Microsoft 365. Short retention can remove evidence before a delayed report reaches IT. Default audit and sign-in retention These periods apply to standard Entra records. Entra licence Sign-in logs Audit logs Free 7 days 7 days P1 30 days 30 days P2 30 days 30 days Identify the tenant’s Entra entitlement in its subscription records. Check the retention period for each relevant record type, including provisioning logs. Microsoft 365 Business Premium includes Entra ID P1, but a Microsoft 365 subscription doesn’t automatically mean P2. Platform defaults don’t set your organisation’s own data retention policy, so check applicable compliance requirements when choosing settings. Upgrading the licence doesn’t recover sign-in records that have already expired. Audit logs record directory changes; sign-in logs record authentication activity. Provisioning logs cover account creation, updates and removal through provisioning processes, and their retention should be checked separately. These datasets answer different investigation questions. Risk history and Unified Audit Log records Microsoft’s retention table lists up to 90 days for P2 risky-sign-in history, 60 days beyond standard 30-day retention. This security-signal history doesn’t extend every ordinary sign-in record. The Microsoft Purview Unified Audit Log is separate. Audit Standard normally retains records for 180 days; eligible Audit Premium licensing provides 1-year retention for qualifying
Cyber security remediation: prioritise findings by risk
Cyber security remediation should prioritise exploitable weaknesses on exposed, business-critical systems, rather than follow severity scores alone. A workable vulnerability remediation plan records each affected asset, its business impact, named owner, required fix, deadline and evidence for closure. Scanning identifies potential problems, but it doesn’t establish which ones need immediate action. Start by separating permanent fixes from temporary controls, then assess each finding against your organisation’s actual exposure. Key takeaways Prioritise known exploitation, reachable attack paths and business impact before using severity scores to order the remaining work. Give temporary mitigations an owner, review date and clear trigger for permanent remediation. Close findings only after validation, and measure unresolved risk alongside mean time to remediate. What cyber security remediation should remove Remediation removes the underlying weakness Remediation is the permanent fix that removes a vulnerability’s root cause. This usually means installing a patch, correcting a configuration, changing vulnerable code or removing an unsupported system. Mitigation reduces the likelihood or impact of exploitation when an immediate fix isn’t feasible. Network isolation may prevent access to a vulnerable service, but the weakness remains until it’s corrected or the service is removed. Arctic Wolf describes its vulnerability management lifecycle as Discover, Assess, Harden and Validate. These stages connect discovery, corrective action and validation as part of vulnerability management, helping improve your security posture. A scan report alone completes neither hardening nor validation. Incident response has a different starting point Vulnerability remediation addresses weaknesses; incident response addresses suspected or confirmed compromise. Patching an exploited server doesn’t remove stolen credentials, malicious accounts or persistence mechanisms. Infinity Group describes detection and limiting further spread, eradication, recovery, and reporting and learning. ArmorPoint uses identification, restricting access, eradication, recovery and prevention. These are incident-response sequences, rather than substitutes for ongoing vulnerability management. If exploitation is suspected, begin containment and investigation alongside the fix. Our cyber incident response services support assessment, containment and recovery when a finding may already have become an incident. What the patching figures do and do not show Arctic Wolf reports that nearly 60% of investigated incidents involving vulnerability exploitation concerned a vulnerability assigned a Common Vulnerabilities and Exposures (CVE) identifier before 2023. This concerns a defined incident subset, not 60% of all breaches. Its 2023 survey reporting also said 18% of organisations planned to implement or improve patch management within the following year. That measures planned improvement, not whether the remaining organisations patched systems. Arctic Wolf also cites Ponemon Institute research stating that 60% of breaches could have been prevented with a proper patch; this is a historical attribution, not a current UK breach rate. SentinelOne states that 46% of cyberattacks occur in organisations with fewer than 1,000 employees. Bugcrowd cites Positive Technologies research finding high-risk vulnerabilities on external network resources at 84% of tested companies. Neither figure establishes the probability of an attack against an individual UK business. The practical implication is narrower: older weaknesses and smaller organisations belong in the remediation programme. Concentrating on newly announced vulnerabilities can leave long-standing, reachable weaknesses unresolved. How to prioritise findings by risk 1. Confirm affected assets and exposure Vulnerability scanning identifies candidate findings for investigation, but scans don’t set priority. Confirm the affected product, version, configuration, owner and business service. Deduplicate scanner findings without losing separate affected instances, and distinguish confirmed vulnerabilities from findings that need investigation. Use a risk assessment to establish whether an attacker can reach the vulnerable component through the internet, remote access, another compromised device or an authenticated account. Map the attack surface to include cloud resources, network appliances and unsupported applications. Our managed vulnerability management services connect discovery and assessment with exploitation evidence, risk-based prioritisation and follow-up review, all within one vulnerability management process. 2. Combine severity with exploitation and business impact The Common Vulnerability Scoring System (CVSS) describes technical severity. The FIRST CVSS specification provides the framework, but a base score doesn’t establish your organisation’s complete risk. Add known exploitation, available attack methods, access requirements, existing controls and the consequences of compromise. Use threat intelligence to assess active exploitation and plausible attack paths available to threat actors. CISA’s Known Exploited Vulnerabilities catalogue provides evidence of exploitation; absence from it doesn’t prove safety. Use risk-based prioritisation to organise the queue. Finding context Priority decision Known exploitation affecting a reachable, critical service Contain exposure immediately and expedite remediation. Severe, reachable weakness without confirmed exploitation Arrange an urgent, tested change. Vulnerable component behind effective access restrictions Schedule remediation and review the restrictions. Evidence confirms the asset is not affected Document the evidence and correct the finding. A lower-scoring weakness can therefore outrank a critical finding on an unreachable component. Document the reason whenever business context changes the order. Turn priorities into an owned remediation plan 3. Assign accountable owners and deadlines Each finding needs a technical owner and a business owner who can approve disruption or accept residual risk. Record the asset, evidence, priority rationale, vulnerability remediation, owners, deadline, dependencies and validation method in the work item. SentinelOne recommends CVSS classification and addressing critical vulnerabilities within 24 or 48 hours. Treat those as suggested response targets, not universal UK legal deadlines. Active exploitation may require immediate steps to limit exposure before testing finishes. Keep internal remediation timelines separate from contractual, certification and regulatory compliance obligations. Where certification is in scope, include work identified through Cyber Essentials preparation and remediation, rather than assuming certification covers every business risk. 4. Plan testing, deployment and rollback Identify application dependencies, maintenance windows, restart requirements and recovery arrangements before deployment. Testing should reflect the affected service, including authentication, integrations and essential transactions. For urgent weaknesses, shorten the change process through pre-approved emergency procedures rather than omitting ownership or validation. If testing delays the fix, reduce exposure during that interval. The NCSC vulnerability management guidance provides an organisational framework for directing this work. Record exceptions with an approver, expiry date and review trigger; an indefinite exception leaves the original decision unchallenged. When mitigation should precede patching Use vulnerability mitigation when no patch is available or deployment can’t
Microsoft Copilot governance: setting business rules
AI governance for Microsoft 365 Copilot defines which information AI can use, who can use it and how activity is monitored. Microsoft 365 Copilot respects existing permissions, so employees may find an overshared payroll spreadsheet through AI. The practical priority is permission hygiene, supported by sensitivity labels, data loss prevention, audit records and clear ownership. Start with the information Copilot can reach, then establish separate controls for agents that connect to systems or perform actions. Key takeaways Review permissions before enabling wider access; Copilot does not correct existing oversharing. Separate Microsoft 365 content controls from Copilot Studio agent approval, identity and publishing controls. Assign owners to permissions, labels, alerts and access reviews. A configured policy needs someone accountable for maintaining it. Map Microsoft Copilot governance to licence tiers Microsoft groups Copilot controls into 3 pillars: data security, AI security, and compliance and privacy. Its framework distinguishes foundational controls associated with A3/E3/G3 licences from optimised controls associated with A5/E5/G5 licences. These are planning groups, not a promise that every feature is included in every plan. Individual feature entitlements, Copilot licensing and relevant add-ons still apply. Use the groups to identify the controls your governance plan requires. Governance pillar Foundational controls, A3/E3/G3 framework Optimised controls, A5/E5/G5 framework Data security Permissions, sensitivity labels, sharing controls and relevant data loss prevention (DLP) capabilities Advanced data classification, investigation and risk controls AI security Approved usage, access controls and supported Copilot safeguards Additional Purview and Defender for Cloud Apps controls Compliance and privacy Supported Audit and eDiscovery capabilities Advanced investigation, compliance and risk management capabilities The distinction matters when budgeting. Buying Copilot does not automatically provide every advanced security or compliance capability. Microsoft’s Copilot security and governance framework identifies the relevant control groups. Our Microsoft 365 services can support the access, authentication and permissions work beneath them. Find and restrict overshared content Identify exposure before the pilot Run SharePoint data access governance reports to identify oversharing and potentially sensitive sites. Microsoft recommends running these reports quarterly, rather than treating discovery as a one-off exercise. Review broad groups, external guests, anonymous links and inherited permissions. Include OneDrive sharing, Teams-connected sites, recordings and transcripts, since confidential information may sit outside the document libraries initially selected for review. As part of ongoing data governance, assign a content owner to each finding. The owner should establish who needs access, whether the information remains necessary and which permissions should be removed. Our Teams Copilot governance checklist covers meeting content and channel access. Distinguish discovery restrictions from access restrictions SharePoint Restricted Content Discovery can temporarily reduce a site’s appearance in search and Copilot responses while permissions are reviewed. Restricted Content Discovery reduces discoverability; it does not remove the underlying permission to access content. Restricted Access Control addresses a different requirement: limiting site access to a defined group. Use the appropriate control, then correct unnecessary permissions rather than leaving discovery restrictions as the permanent answer. Prioritise sites holding HR records, financial information, client material and commercially sensitive plans. A low-activity site can still contain high-risk information. Apply usable labels and data protection Keep the label structure manageable Microsoft Inside Track recommends no more than 5 parent labels with 5 sub-labels each. This is a usability recommendation based on Microsoft’s internal practice, not a mandatory product limit. Create sub-labels only when they change handling requirements, such as external sharing or encryption. Employees who can’t reliably distinguish labels will classify information inconsistently. Document what each sensitivity label does. A label may classify information, apply encryption or configure container labels. Container labels don’t automatically apply the same label to every file within a site. Configure the protection behind the label Copilot respects sensitivity labels and applicable data loss prevention (DLP) controls. However, a document marked “Confidential” isn’t automatically excluded from Copilot. Microsoft Purview DLP can prevent selected labelled files and emails from being processed for responses. The policy must be configured, and its scope must match the content and users concerned. Microsoft Purview’s AI protections cover these capabilities. Our guidance on Purview controls for AI risks explains the difference between classification and enforced restrictions. Test permitted and prohibited behaviour with approved test content before expanding the pilot. A published policy doesn’t prove that every relevant route is covered. Write business rules staff can follow An AI usage policy should identify approved tools, permitted information, prohibited activities and who handles exceptions. State whether staff can get self-service access to approved AI tools. “Use AI responsibly” doesn’t establish a usable business rule. State whether staff may submit client information, employee records, source code or commercially sensitive material. Where use is permitted, specify the approved Microsoft environment and required protection. Require human review before AI-generated material becomes external advice, a contractual commitment or an operational decision. Copilot’s ability to access a document doesn’t establish that the document is current or that its answer is correct. Unapproved personal AI accounts, browser extensions and connected applications are shadow IT, even when the underlying service is familiar. Detect and review those connections through available application inventories, consent records and security tooling. Our IT consulting services can help connect these rules with licensing, platform decisions and implementation responsibilities. Govern Copilot Studio agents separately Establish agent ownership and identity Copilot Studio adds another governance requirement because agents can use connectors, retrieve information and perform configured actions. A Microsoft 365 permissions review doesn’t replace an agent approval process. Agent 365 is Microsoft’s central control plane for observing, governing and securing agents. For organisations that onboard it, Copilot Studio agents can be represented as identities in Microsoft Entra and governed with Conditional Access. Record each agent’s owner, purpose, connected systems and authorised actions. Apply least privilege to its access, in line with Zero Trust principles. Our cyber security services can support the wider identity and access controls involved. Control publishing, connectors and data movement Administrators can disable publishing of agents using generative AI through the Power Platform admin center. Use Power Platform data policies to govern connector combinations and prevent unapproved connections. Review these data
IT asset lifecycle management: when to replace equipment
Replace business equipment when it can no longer meet security, reliability or workload requirements at an acceptable cost. For laptops, a 3 to 5-year refresh window is a useful planning assumption, but age alone does not justify replacement. IT asset lifecycle management provides the records needed to make that decision, including support deadlines, repair history, ownership and operating costs. Start by distinguishing an equipment replacement schedule from a process that manages assets throughout their working life. Key Takeaways IT asset lifecycle management tracks equipment from planning and procurement through deployment, operation, maintenance and retirement. Keep ownership, support, cost and custody records with each asset. A 3 to 5-year laptop refresh window helps forecast expenditure, but age alone doesn’t justify replacement. Review security support, workload, reliability, repair history and operating costs. Compare repair, reassignment and replacement over the same period, including downtime, support time, migration effort and disposal costs. Software licences and cloud resources need owners, renewal dates and retirement plans. For physical equipment, record sanitisation evidence and the final disposal destination. What IT asset lifecycle management covers IT asset lifecycle management tracks technology from planning through acquisition, deployment, use, maintenance and retirement. It links technical condition to financial records, contractual obligations and the business services each asset supports. ISO/IEC 19770-1:2017 specifies requirements for an IT asset management system. ITIL 4 describes lifecycle stages through the statuses an asset attains between planning and disposal. There is no universal number of stages. Splashtop, Tanium and Atlassian use five-stage models, while Virima and ServiceNow use six. Treating procurement or reassignment as a separate stage changes the structure, not the underlying responsibilities. Tanium also distinguishes financial, useful and economic life. An asset can be fully depreciated yet remain useful. Conversely, equipment with remaining accounting value may already cost too much to operate. That distinction matters when setting budgets. Accounting treatment should inform a replacement decision without determining whether equipment remains secure or suitable. The 5 lifecycle stages and their records A practical asset lifecycle model groups planning and purchasing, then tracks equipment through four further stages. Each stage needs an owner, an approval point and records that remain attached to the asset. Stage Main activities Records to retain Planning and procurement Define requirements, approve expenditure and select equipment. Business purpose, specification, supplier, cost, warranty and expected review date. Deployment Configure, protect, register and assign the asset. Serial number, asset tag, assigned user, location, encryption and in-service date. Operation Monitor usage, ownership, performance and support status. Last-seen date, utilisation, installed software, incidents and ownership changes. Maintenance Patch, repair, upgrade and review suitability. Repair costs, downtime, battery condition, firmware and support deadlines. Retirement and disposal Recover data, remove access, sanitise and select a disposal route. Approval, custody transfers, sanitisation evidence and final destination. Consistent asset management records should follow each asset through handovers, rather than replace earlier entries. Where used, link the asset register to the organisation’s CMDB. A reassigned laptop still needs its purchase information, previous repairs and sanitisation history. A missing handover record creates practical problems. IT may order another device because an available laptop cannot be located, or finance may continue paying for equipment already returned to a leasing company. Build an asset register that survives each handover Use durable identifiers and record custody Register equipment before deployment. Device42 recommends barcodes, QR codes or radio-frequency identification (RFID) tags for traceability. Virima recommends serial numbers, BIOS UUIDs or cloud instance IDs instead of hostnames, which can change during re-imaging. Record the assigned person, responsible department, physical location and lifecycle status. Include spare, leased, remote and offline equipment in the asset inventory. Network discovery alone won’t reliably identify a laptop stored in a cupboard. For overseas offices, our global IT support can help maintain consistent device deployment and support processes across locations. Separate ownership records from service relationships An asset register records ownership, cost, location and status. A configuration management database (CMDB) records configuration items and their relationships, such as which application depends on a particular server. The systems can share information, but neither label proves the records are complete. Accurate records support IT asset management and lifecycle decisions. Flexera’s 2025 ITAM findings reported complete technology visibility at 43%, down from 47% the previous year. Tanium distinguishes comprehensive visibility, which covers all assets, from lifecycle visibility, which covers each asset’s stages. Both matter during an IT support provider handover. Linked records in the CMDB can show a device’s warranty, owner and retirement approval, details that discovery alone can’t provide. When should businesses replace their equipment? Use age to schedule reviews Laptops commonly operate efficiently for 3 to 5 years, according to Atlassian. Sage’s 2026 benchmarking report found average laptop refresh cycles shortened from 4.3 to 4.0 years in 2025. For asset lifecycle planning, use that range to forecast expenditure, then review each device’s condition and workload. Battery deterioration, repair frequency, maintenance history, application requirements and vendor support can justify an earlier or later replacement. Atlassian contrasts laptop life with electrical switchgear lasting around 15 to 30 years. That comparison is not a recommended lifespan for Ethernet switches. Network equipment needs separate review against firmware support, capacity and recovery requirements. Treat support and security as decision gates Equipment should be replaced, upgraded or removed when required operating systems, firmware or security controls are no longer supported. A functioning device can remain unsuitable if it can’t receive necessary security fixes. IBM’s 2026 breach report puts the global average breach cost at US$4.99 million. That figure isn’t an estimate of the loss caused by an old laptop, but it supports treating data protection as part of lifecycle decisions. A warranty extension can cover eligible hardware failures. It doesn’t extend operating-system support or make an unsupported application secure. Review these conditions before approving another year of use. Repair, reassign or replace: compare the remaining cost Repair when the underlying platform remains suitable A battery replacement or supported storage upgrade may extend useful life if the device still meets performance and security requirements. Check the repair cost, expected downtime,
IT due diligence: an acquisition checklist for leaders
An acquisition can look financially sound while its M&A transaction assumptions overlook inherited technology costs. IT due diligence examines the target’s systems, security, software, suppliers and operating capability before those commitments become yours. The review should identify what could interrupt trading, restrict growth or increase integration costs, then connect each finding to a decision. Start with the acquisition plan, because technology that supports the target today may not support the combined business. Key Takeaways IT due diligence assesses whether the target’s technology can support the acquisition’s commercial assumptions and identifies what the buyer will inherit, need to invest in and integrate. Review systems, software, cyber security, data protection, infrastructure, recovery, suppliers, contracts, staffing and operating costs against the deal plan. Base findings on evidence and record each issue’s business impact, supporting evidence, owner, proposed treatment and estimated cost. Resolve material issues before signing where access permits. Carry any remaining uncertainty and remediation work into the acquisition terms, budget and integration plan. Establish what IT due diligence must answer IT due diligence assesses whether the target’s technology can support the acquisition’s commercial assumptions. It should establish what the buyer will inherit, what needs investment and which dependencies could prevent the planned integration. A reliable inventory helps, but it doesn’t establish whether systems are secure, recoverable or suitable for expansion. Separate the overlapping workstreams: IT due diligence examines infrastructure, applications, support, suppliers and operating costs. Technical due diligence examines software architecture, code quality, development practices and product scalability. Cyber due diligence examines exposure, access controls, incident handling and security operations. For a software business, architecture and intellectual property may dominate. For a professional services acquisition, identity, Microsoft 365, document access and business continuity may matter more. Base IT due diligence questions on the deal’s commercial assumptions. Cover expected user growth, international operations, planned integrations, data pipelines that support these plans and assumed cost savings. Assign owners and sequence the review Appoint a deal sponsor who can resolve commercial questions and a technical lead who can challenge the evidence. Involve legal, finance, security and operational owners where findings affect contracts, forecasts or continuity. Specialist advisers can provide independent scrutiny, but management still owns the acquisition decision. Use a sequence that follows dependencies rather than treating each assessment as an isolated exercise: Define the IT due diligence scope, material systems, business assumptions and access arrangements. Request evidence through a controlled data room against the agreed scope and deal assumptions, with named owners for missing information. Review architecture and software components, then commission appropriate code analysis. Assess cyber security, data management, infrastructure and recovery capability. Review contracts, staffing, operating costs and integration dependencies. Produce a prioritised report with commercial implications, remediation owners and estimated effort. Request architecture diagrams, asset registers, supplier contracts, security reports, recovery records and annual expenditure early. Missing evidence should remain an explicit limitation, rather than becoming an assumption that controls exist. Resolve material issues before signing where access permits. If an assessment must wait, document the uncertainty and its proposed treatment with the deal team. Review software architecture and code Examine design before relying on scan results During technical due diligence, review the software architecture. Check how applications exchange data, authenticate users, separate customers and handle increased demand. Establish which systems depend on unsupported frameworks, undocumented interfaces or manual intervention. Code scanning can identify security vulnerabilities and code quality issues, but it can’t establish whether the architecture supports the acquisition plan. Ask developers to explain deployment, testing, rollback and the effort required for planned changes. Technical debt is future work created by expedient implementation choices or deferred improvements. Record the affected components and business consequences. A backlog count alone doesn’t show whether delivery is constrained. Request an SBOM and establish ownership A software bill of materials, or SBOM, inventories open source components and their dependencies. It’s a starting point for identifying third-party licences and known vulnerabilities, not proof that every component is acceptable. Black Duck’s explanation of an SBOM describes its role in documenting open-source and third-party components. Compare the inventory with deployed versions, dependency records and supplier information. Review open source licence obligations with legal advisers, including distribution conditions and restrictions relevant to the intended use. Establish who owns custom code and whether employee, contractor and supplier agreements support that ownership. Assess infrastructure, cloud and recovery Request IT infrastructure inventories, including servers and hardware, network topology, cloud architecture, administration procedures and annual IT spend. Reconcile recorded IT infrastructure assets with management tools, invoices and support arrangements. Technical due diligence should examine cloud ownership, privileged access, resource configuration, billing commitments, capacity and recovery evidence. Separate current expenditure from costs that will change when contracts end or workloads move. Recovery evidence needs particular attention. Compare business recovery requirements with recorded restore tests, backup coverage and dependencies such as identity, connectivity and encryption keys. A successful file restore doesn’t demonstrate recovery of an entire application. Microsoft 365 also needs its own review. Tenant configuration, licences, permissions and retention settings can affect both security and migration effort. Our Office 365 assessment guide describes the relevant review areas. Where tenant consolidation is planned, involve Microsoft 365 migration support before agreeing dates. Existing email, Teams and SharePoint arrangements influence the work required. Examine cyber security and data protection Assess controls through evidence Use cyber due diligence to assess controls against evidence. Request privileged-account records, multi-factor authentication coverage, endpoint protection reports, patching evidence, penetration-test findings and incident response procedures. Identify unresolved security vulnerabilities and record who accepted each risk. Legal Edge reports that Intechnica found security issues in 1 in 5 businesses across more than 250 engagements in its technology due diligence overview. This finding from those engagements should not be treated as an industry-wide prevalence estimate. Assess authentication methods as well as coverage. The NCSC’s corporate MFA guidance recommends stronger protection against phishing. An enabled setting doesn’t prove that every privileged access route is protected. Review incidents and data obligations Map personal data, processing purposes, processor relationships, retention and international transfers. Review compliance with UK
Microsoft 365 access reviews: remove unnecessary permissions
A denied decision doesn’t always remove the underlying permission. These reviews help identify unnecessary group memberships, application assignments and privileged access, but removal depends on the resource type, review settings and how access was originally granted. Start by identifying those access paths, then configure reviewers, recurrence and enforcement. The useful outcome is confirmed removal, supported by evidence, rather than a completed review with outstanding changes. Key Takeaways Microsoft 365 access reviews check whether people still need access to groups, applications and privileged roles. They don’t replace joiner, mover and leaver procedures or sign-in controls. Check access paths beyond group membership, including direct SharePoint permissions, shared links, Teams shared channels and mailbox delegation. A denied decision doesn’t prove that access has been removed. Apply results where supported, check the status and record completed changes or assigned remediation. Choose reviewers with the right business context, set suitable review dates and recurrence, and pilot removal before enabling automatic application. Include active and eligible privileged role assignments in reviews, and retain decisions, justifications and remediation evidence. Define what Microsoft 365 access reviews will cover Separate permissions from sign-in controls An access review is a periodic check of whether someone still needs access. Reviewers decide whether user access to scoped resources should continue. These checks help prevent privilege creep, where permissions accumulate after role changes, temporary projects and supplier engagements. They support least privilege and compliance, but don’t replace joiner, mover and leaver procedures. Conditional Access addresses a different question: under what conditions an account may sign in. A successful sign-in doesn’t prove that existing access permissions are still appropriate. Identify access paths before selecting resources Inventory sensitive Teams, groups, enterprise applications and administrative roles. Record resource owners and group owners, the business purpose, membership source and whether external guests have access. Group membership is only part of the picture. SharePoint direct permissions, Anyone links, Teams shared channels and mailbox delegation may need separate checks. Our Office 365 assessment covers wider configuration and permission issues a group-focused review may miss. Check licensing against the review scope; Microsoft Entra ID Governance features depend on your subscription. Configure reviews in Microsoft Entra Select resources and accountable reviewers For standard group and application access reviews in Microsoft Entra ID, use an account with at least the User Administrator role. Follow Microsoft’s access review configuration guidance and begin with a limited pilot. Sign in to the Microsoft Entra admin center. Open Identity Governance, then start a new review. Select Teams + Groups or Applications, then choose the resources and users within scope. Select Next: Reviews and assign the reviewers. Choose reviewers who understand the business need, rather than whoever receives the fewest notifications. Group owners can assess collaboration access; application owners may be better placed to assess specialist systems. Provide a fallback reviewer in case the selected person is absent or unavailable. A self-review can gather information, but a user’s own decision to approve or deny sensitive access is weak evidence. Set stages, duration and recurrence A single-stage review lets assigned people make decisions within one stage. A multi-stage review uses two or three sequential stages with different reviewer groups. Use a multi-stage review when a decision needs different perspectives, such as business justification followed by application-owner approval. Extra stages extend the process and increase workload. Set Stage duration in days. When it ends, reviewees move to the next configured action or stage. Set the start date and Review recurrence, such as monthly or yearly, according to the resource’s sensitivity and rate of change. Schedule a review around quarter end when that fits the resource’s risk or reporting cycle. Set what happens when reviewers do not respond For access reviews, the non-response setting determines what happens when an item remains undecided. It doesn’t prove that access permissions have been removed. Applying results is a separate step, and removal depends on whether the resource supports the change. Use these settings together rather than treating each as an independent safeguard. Setting Effect Practical consideration Auto apply results to resource Applies decisions after the review expires, including removal of denied access where supported. Pilot removal before using it across sensitive resources. No change Leaves unanswered access unchanged. Escalate outstanding decisions rather than recording them as approved. Remove access Treats unanswered items as removal decisions. Allow for reviewer absence and business-critical access. Approve access Approves unanswered items. Silence doesn’t establish a continuing business need. Take recommendations Uses system recommendations for unanswered items. Understand which signals produced the recommendation. The No sign-in within 30 days recommendation favours approval for users who signed in within that period and denial for those who didn’t. Recent activity is evidence of use, not proof of need. An employee can use a system regularly while retaining permissions beyond their current responsibilities. Enable email notifications and reminders, and require a decision justification where appropriate. During a pilot, apply results manually so administrators can inspect proposed removals before enabling automatic enforcement. Use catalog reviews for related resources Bring multiple resource types into scope A catalog access review requires Microsoft Entra ID Governance or Microsoft Entra Suite subscriptions. Creating one requires at least the Identity Governance Administrator role, so don’t assume the role used for a standard group review is sufficient. A catalog access review can include groups, applications and custom data-provided resources. Reviewers can assess related access together instead of reviewing each resource in isolation. Under Entitlement management, open Catalogs, select the catalog, then Resources and Add resources. Microsoft’s catalog access review documentation describes the configuration and supported resource model. Allow for timing and enforcement differences Changes made within 12 hours before a catalog access review starts may not appear in its results. Don’t treat last-minute membership cleanup as the baseline for a scheduled review. Record which resources were included and when the review started. This makes later differences between review data and current membership easier to explain. Adding resources to a catalog doesn’t guarantee that every target system can remove access automatically. Document the removal process for each resource,
