Entrazure
What we build
Tenant governance that survives the first exception. A naming and lifecycle model for sites and teams, provisioning that assigns an owner and a review date at creation, external sharing defaults set deliberately, and guest access governed through Microsoft Entra ID B2B with expiry rather than permanence. Administrative roles move to Privileged Identity Management, so global administrator becomes something you request for an hour, not something four people hold forever.
Intune and device compliance. Enrollment, compliance policies, configuration profiles and update rings, sequenced in report mode before anything is enforced. Compliance means nothing on its own, so it is wired to conditional access: a non-compliant device stops being a line in a dashboard and starts being a device that cannot open the payroll site. Personal and contractor devices are handled with app protection policies instead of full management.
Teams and SharePoint architecture. A structure that reflects how work is organized rather than how the org chart was drawn: which content belongs in a team, which belongs in a document library with defined permissions, what happens to a project team when the project ends, and where retention applies. Archiving and disposal are designed at the same time as creation, because a tenant with no exit path accumulates permanently.
Classification and protection. Microsoft Purview sensitivity labels with a taxonomy short enough that people actually pick one, auto-labeling for the categories that can be detected reliably, and data loss prevention where the risk justifies the friction. Labels are the mechanism that keeps a document out of a generated answer, which is why they are built here and not improvised during a Copilot pilot.
Migration, when it applies. From Google Workspace or on-premise Exchange: mail, files, groups and the sharing model, into a tenant that was governed before the data arrived.
Permission hygiene is the part that decides everything else
Microsoft 365 Copilot grants no new access. It answers from what the user can already open, in one sentence of plain language, without needing to know the document exists. That is the whole risk, and it is not a Copilot defect. It is a decade of people helping each other quickly: a folder shared with Everyone Except External Users to close an access complaint, an anonymous link created for a supplier who has since been replaced, a finished project team still holding its files and still open to its original membership, a departed employee’s OneDrive inherited by a manager and never reviewed.
Our Copilot deployment service audits and remediates enough of that to make one rollout safe, and the Copilot rollout solution explains why a rollout without the audit turns into an incident. Both stop at the edge of the same problem: they clean up the consequence. If the sharing defaults, the provisioning path and the ownership review that produced the mess stay untouched, the tenant regenerates it, and the next audit finds a new set of the same findings two years later.
So this engagement works upstream. Sharing defaults are changed at the tenant and site level. Every site and team gets a named owner and a recurring access review. Broad-scope links are scoped or removed and the setting that allowed them is corrected. Ownerless sites are dispositioned rather than inherited. Sensitive content is labeled where it lives instead of being chased around the tenant. The result is a permission estate that stays defensible without anyone auditing it by hand, which is the state Copilot needed in the first place.
How the engagement runs
Week 1, assessment and decisions. Permission and sharing reporting across SharePoint and OneDrive, device inventory and compliance gap, admin role review, and the workshop that settles the expensive choices: sharing posture, lifecycle rules, label taxonomy, device enforcement sequence. Output is a decision record and a ranked remediation backlog with an effort estimate against each item.
Week 2, identity and device baseline. Conditional access reviewed and rebuilt where it has gaps, privileged roles moved behind time-bound approval, Intune compliance policies deployed in report mode, app protection policies for unmanaged devices.
Week 3, collaboration architecture and remediation. Site and team lifecycle deployed, sharing defaults corrected, the top of the remediation backlog executed with the real business owners, sensitivity labels published and auto-labeling run in simulation before enforcement.
Week 4, enforcement and handover. Device compliance enforced per group, access reviews scheduled on a recurring cycle, documentation and runbooks written, and working sessions with the people who will own the tenant. The backlog we deliberately left for later is named, with the reason and the trigger for picking it up.
What you keep
- The permission and sharing audit, with the remediation backlog, owners and status per item.
- A written governance model: sharing posture, lifecycle rules, guest policy, admin role model.
- Intune compliance and configuration baselines, and the conditional access policies bound to them.
- A published sensitivity label taxonomy and the auto-labeling policies behind it.
- Runbooks for provisioning, access review, offboarding and site disposal, written for your team.
- The decision record, including the exceptions we granted and the date each one expires.
Who this is for
Organizations of roughly 100 to 5,000 seats running Microsoft 365 as their primary workplace, particularly where the tenant has been live for years, has absorbed a merger, or is about to be pointed at an AI assistant. It is the right engagement when the tenant works well enough day to day but nobody can answer what is shared with whom, and when device compliance exists as a report rather than as a control. It pairs naturally with cybersecurity and Entra ID on the identity side and with compliance architecture where an auditor is involved.
Who this is not for
If you have fewer than about 50 users, one SharePoint site and no regulated content, this is more governance than your situation needs. Set the sharing defaults, appoint an owner, and spend the budget elsewhere.
If the expectation is a tenant cleanup with no change to how people share files, it will not hold. Remediation without changed defaults is a snapshot, and the estate drifts back within a year.
And if the real need is a service desk answering user questions all day, that is not what we sell. Our work is the architecture and the operating model behind it. The managed Azure engagement covers ongoing platform operations, not end-user support.
Related
- Microsoft 365 Copilot deployment, the assistant this groundwork makes safe to enable.
- Copilot rollout without the oversharing incident, the same problem seen from the rollout side.
- Enablement and training, how your team takes the tenant over.
- Cybersecurity and Entra ID, conditional access and privileged identity in depth.
- All Azure services, the full engagement catalog.
Questions we get
We already have Microsoft 365. What is left to build?
Usually the parts nobody was given time for: a site and team lifecycle, external sharing defaults that match your risk appetite, a device compliance baseline that conditional access actually enforces, and an admin role model that is not four permanent global administrators. The licenses were bought years ago. The operating model behind them is what we build.
Is this the same work as the Copilot readiness assessment?
They overlap and they are not the same. A readiness assessment audits the tenant and remediates enough of it for one deployment to be safe. This engagement changes the defaults, the provisioning path and the review cycle that produced the oversharing, so the cleanup does not have to be repeated before the next thing you switch on.
How long does permission remediation take?
The audit is two weeks. The remediation depends entirely on how much history the tenant carries, and we will not quote it before we have counted the sites, the broad-scope links and the ownerless teams. What we commit to at the start is a ranked list with an effort estimate per item, so the budget conversation happens against real numbers.
Do we have to move devices to Intune?
Not on day one, and not all of them. Device compliance only becomes useful when conditional access depends on it, so we sequence it: enrollment and compliance policies first in report mode, then enforcement per user group. Personal devices are handled with app protection policies rather than full management, because insisting on enrolling a contractor's laptop is how a rollout stalls.
Can you migrate us from Google Workspace?
Yes, and from on-premise Exchange. Mail, files, groups and the sharing model, with the target tenant governed before the data lands in it. Migrating an unstructured estate into an ungoverned tenant reproduces the same problem in a more expensive place.
Who runs this after you leave?
Your team, which is the point. The configuration is documented, the recurring tasks have runbooks, and we run working sessions with the people who will own it. If you would rather it stayed with us, that is a separate managed arrangement and it is priced separately.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.