M365 reporting that answers the regulator's question.

Default 90 days for unified audit log; extended to 1 year with E5 Compliance and configurable up to 10 years for specific record types. We activate retention as part of the engagement and document the retention policy for your auditor.

Yes via Power BI cross-tenant queries or audit-log streaming to a unified SIEM. Common for client-services firms managing multiple client tenants, or large organisations with multi-tenant architectures.

Compliance Manager has 200+ regulatory templates including ISO 27001, NESA, DFSA, ADGM, GDPR, HIPAA, PCI DSS. We activate the templates relevant to your regulator and customise as needed.

Per-user Pro for analyst access, Premium per-user (PPU) for some advanced features, Premium per-capacity for large stakeholder distribution. We model the right Power BI licence tier in the discovery.

Yes via Power BI web parts. Dashboards embedded in stakeholder SharePoint sites with role-based filtering. Useful for executive teams who don't want to navigate Power BI separately.

Indicators: regulator review approaching, multi-tenant aggregation needed, multi-year trend analysis required, audit-evidence packaging time-consuming, stakeholders requesting custom views. M365 admin centre serves casual reporting; engineered reporting serves operational analytics.

Yes. Common takeover work: dashboard tuning, retention extension, framework template activation. Most takeovers complete in 3-4 weeks.

For clients on Sentinel, we stream M365 audit logs to Sentinel for advanced analytics, anomaly detection, and SIEM-grade correlation. Power BI dashboards complement Sentinel for stakeholder-friendly reporting.

The regulator is only one of the parties who will eventually ask, and usually not the first. Enterprise customers running supplier security assessments ask the same questions and increasingly make contracts conditional on the answers. Cyber insurers ask them at renewal and price accordingly. Banks ask during enhanced due diligence. Investors and acquirers ask during due diligence, and an inability to evidence access controls at that moment affects valuation rather than merely causing inconvenience. Beyond all of that, the internal case stands on its own: knowing who holds administrative access, what is being shared externally and which devices are non-compliant is basic operational awareness. Unregulated organisations tend to arrive at this work reactively, after a customer questionnaire they could not complete, and reactive is always more expensive.

Only if auditing was already switched on and the retention period covers the date in question, which is the uncomfortable part. Microsoft 365 audit logging records file access, sharing, permission changes, mailbox access, administrative actions and sign-ins, but the default retention is limited and it cannot be applied retrospectively. If somebody asks about an event from fourteen months ago and your retention was ninety days, the answer is that the record no longer exists, and there is nothing anyone can do about it at that point. This is why the first thing we check in an audit-readiness review is retention configuration rather than reporting capability. Extending retention costs licensing rather than effort, and it is the cheapest insurance in the entire compliance stack.

The baseline retention for most audit events is relatively short, longer for certain event types, and extendable through Audit Premium or add-on retention up to substantially longer periods including ten years for specific categories. What matters more than the exact figures, which Microsoft adjusts, is that you make a deliberate decision rather than inheriting a default. The question to ask is how far back a regulator, an insurer, a litigant or your own investigation might reasonably need to look, and for a DFSA or FSRA-supervised firm the answer is usually years rather than months. We check the current configuration, model the licensing cost of the retention you actually need, and where full retention is not affordable across the board we export the critical event categories to durable storage instead, which is a fraction of the cost.

The requests cluster into a predictable set, which is why building them once as repeatable reports beats assembling them each time. Privileged access: who holds administrative roles, when they were granted, and evidence of periodic review. Access recertification: proof that user access was reviewed and signed off, not merely that a list exists. External sharing: what left the organisation, to whom, and whether it was sanctioned. Sign-in anomalies: failed attempts, impossible-travel patterns, and legacy authentication use. Mailbox access by anyone other than the owner, which is a specific question in financial services. Data classification coverage. And change history for security-relevant configuration. We build these as standing reports so an information request becomes an export, and that shift is what turns audit season from a fortnight of work into an afternoon.

Use them where they suffice, and they often do for operational questions. The built-in reports are genuinely useful for usage, licensing and basic activity. Where they fall short is anything requiring history beyond the retention window, anything correlating across workloads, anything comparing against a baseline or a threshold, and anything that needs to be presented to a non-technical audience without interpretation. The other limitation is that they are point-in-time views rather than a record: you can see the state today, but not demonstrate what the state was in March when the auditor is asking. Engineered reporting exists to close those gaps, and the honest test of whether you need it is whether you have ever had to manually assemble a report from several consoles under time pressure.

Yes, and this is usually the highest-value part of the engagement because it converts reporting from retrospective to preventive. The changes worth alerting on are narrow and specific: a new global administrator being created, a mailbox forwarding rule to an external address, a conditional access policy being modified or disabled, a large volume of external sharing in a short period, a sign-in from a break-glass account, an administrative role being assigned outside change control, and mass download or deletion activity. Each of those is either a genuine incident or a legitimate action that somebody should have communicated. The design principle is a small number of high-signal alerts that a human reads every time, rather than a broad rule set that becomes background noise within a month.

Yes, and it is common in UAE holding structures where separate entities hold separate tenants for licensing, regulatory or historical reasons. Cross-tenant reporting consolidates the picture so group IT and the board see one view rather than reconciling several. The considerations worth settling early are data residency, since consolidating into one location may cross a boundary that matters for one of the entities, access control so that each entity sees its own data and only group functions see everything, and consistency of definitions, because entities frequently classify and name things differently and a consolidated report built on inconsistent definitions is worse than no report. We map those before building rather than discovering them at the first board presentation.

By reporting trend and exposure rather than activity, which is a different exercise from operational reporting. A board does not benefit from knowing how many sign-ins occurred; it benefits from knowing whether MFA coverage is complete and improving, how many privileged accounts exist and whether that number is falling, whether external sharing is trending up, how many devices are non-compliant and for how long, and whether identified risks are being closed or accumulating. Three or four measures with a direction of travel and a short narrative beats twenty charts. We build the board pack as a deliberately separate artefact from the operational dashboard, because trying to serve both audiences from one report reliably serves neither.

Increasingly it is the difference between a smooth renewal and an awkward one. Insurers now ask specific, verifiable questions: what proportion of accounts have MFA, is it phishing-resistant for administrators, how many privileged accounts exist, is there EDR on every endpoint, are backups tested and immutable, and how quickly are critical vulnerabilities remediated. Answering those from a maintained report rather than from memory produces both a faster process and a better outcome, because a precise answer supported by evidence reads differently from an approximate one. We have had clients use the same reporting pack for insurance renewal, a customer security assessment and a regulator information request in the same quarter, which is the point of building it once properly.

It happens, and the honest position is that you cannot recover the past, so the response is to fix the present quickly and be straightforward about the gap. Unified audit logging is enabled by default on newer tenants but has been found disabled in older ones or after a migration, and the first anyone notices is usually during an investigation when there is nothing to look at. The immediate actions are to enable it, extend retention to the period your obligations require, configure the alerting for high-risk changes, and document the date from which reliable records exist. If an auditor or investigator asks about an earlier period, saying clearly that logging was not enabled before a stated date is far better than producing partial data that implies more coverage than existed.

Three to six weeks for a full reporting and alerting build, and the pace depends mostly on how quickly we can agree what the reports need to say. Week one is requirements: who consumes each report, what decision it supports, and which obligations drive it. Week two covers configuration, enabling and extending audit retention and closing any logging gaps. Weeks two to four build the reports and dashboards, with a review cycle because the first version is never quite right. Weeks four to six configure alerting, tune out the noise, and hand over with documentation. What we need from you is a named owner per report who will actually read it, and access to whoever holds the compliance requirements, since building reports against assumed obligations is how you end up with beautiful dashboards nobody asked for.

Yes, and most clients take it that way because a report nobody produces has no value regardless of how well it was built. The managed arrangement covers producing and circulating the monthly pack, monitoring and triaging the high-signal alerts, keeping the reports current as Microsoft changes the underlying data and as your obligations change, refreshing the evidence pack quarterly so it is always audit-ready, and completing customer security questionnaires and insurer forms from the maintained data. The pattern we see with self-managed reporting is that it works well for two or three months and then degrades as the person who owned it gets busy, which is precisely when an information request tends to arrive.

Long enough to cover the questions you might realistically be asked, which for most regulated UAE firms means years rather than months. The practical way to decide is to work backwards from who asks: a regulator during a periodic review, an insurer at renewal, a customer running a supplier assessment, a litigant, or your own investigation after an incident discovered late. Incidents in particular are frequently found months after they began, and if your retention window closed before the relevant event you simply cannot answer. Where full retention across every event type is not affordable, we export the critical categories to durable storage instead, which costs a fraction and covers the questions that actually get asked.