Defined implementation
Know which accounts are properly protected, and be able to prove it.
Configure the agreed sign-in methods, administrator roles, emergency access and access policies. Test them with a pilot group before enforcement and record the results.
PricePrice fixed after a short scope call.
Delivery4 to 6 weeks
What you receive · illustrative sample
A policy change comes with a validation record.
Illustrative policy register. Enforcement follows a pilot, emergency-access checks and written authorization.
| Control | Before enforcement | Evidence retained |
|---|---|---|
| Conditional Access | Report-only review and pilot users | Policy settings and sign-in results |
| Privileged access | Role ownership and activation requirements | Role/approval register |
| Emergency access | Controlled sign-in and alert test | Restricted-access runbook |
Meet the person responsible for delivery.
Alwatheq Zboun leads the agreed work. A sample shows the format; the statement of work defines your deliverable and acceptance checks.
Engagement context
When this engagement applies.
Sign-in methods are mixed, administrators hold permanent rights, and there are policy exceptions nobody can explain.
Scope considerations
- One Microsoft 365 tenant
- Sign-in path mapped at scoping
- Client owns end-user communications
The defined work
Engagement scope.
- 01
The authentication method inventory is produced from the tenant: who signs in with what, including the accounts on nothing.
- 02
The agreed target methods are configured and rolled out group by group, with a pilot ring first.
- 03
Standing administrator roles are reduced to eligible assignments, and emergency access is created, excluded from the policy set, and tested.
- 04
A bounded Conditional Access policy set is deployed in report-only first, then enforced against the agreed populations.
- 05
Every exception is recorded with an owner, a reason, and a review date, and the evidence pack is assembled from the live tenant.
Acceptance
Completion has an agreed standard.
Done when the approved user and administrator populations meet the agreed rules and every policy test passes or has a named exception.
Admin MFA is enforced and legacy authentication is blocked
The agreed Conditional Access set is deployed in its approved enforcement state
Emergency-access accounts exist, are excluded from the policy set, and alert when used
Named tests pass and the evidence packet is delivered
Commercial basis
Price, scope and timing are considered together.
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- User and administrator population
- Number of existing Conditional Access policies
- Applications authenticating through Microsoft 365
- Named-user exceptions to carry
- Licensing tier available for the controls in scope
Scope & responsibilities
The full engagement boundary.
Review the exclusions, required client participation, change controls and operational handover for this engagement.
Exclusions
- ADFS or third-party federation migration
- Service-account redesign
- Penetration testing
- Any guarantee that an insurer or auditor approves the environment
- Help desk and end-user support
Client responsibilities
- Distribute enrollment communications
- Handle routine enrollment questions from staff
- Approve the exception list and nominate an owner for each
- Provide administrative access and approve change windows
Change and rollback method
- Policies go in report-only before they are enforced, and enforcement is staged group by group with a pilot ring first.
- Rollback is the previous policy state, captured before the first change and re-appliable within one change window.
- Emergency-access accounts are confirmed excluded and alerting before any enforcement date is set.
Operational record and handover
- The authentication method inventory, before and after
- The Conditional Access policy register, with the reason each policy exists
- The administrator role register and eligible-assignment configuration
- Test results against the agreed populations
- The exception register, with owners and review dates
- The evidence pack, assembled from the live tenant for an auditor or insurer to read
Before you commit
A clear first step.
You stay in control.
Start with the problem and the result you need. The initial fit conversation is free and does not require access to your systems.
Check client feedback on Upwork ↗Prefer to contract through Upwork? Contact Alwatheq there. Existing Upwork engagements continue through Upwork.
Who will actually do the work?
Alwatheq Zboun leads the scope, technical work and handover. If a specialist collaborator is needed, their role is agreed with you before work starts. Your proposal names the responsibilities and delivery windows.
What happens before you get access?
We agree the scope, fee and completion checks in writing. Access uses named accounts and only the permissions the work requires. Approved access is reviewed and removed at handover.
How do we know the change worked?
Your scope defines the pilot, test cases and acceptance checks. Results and exceptions are recorded. Recovery options and their limits are agreed before production changes; a failed check is addressed before the next approved stage.
Will we need an ongoing retainer?
A defined project can end at handover. Your team receives the agreed configuration records, runbook and walkthrough. Any limited support period is written into the proposal; ongoing support or additional work is a separate agreement.
Discuss this engagement
Put the scope in context.
Describe the problem, systems and deadline. Alwatheq will review the fit and the scope questions before preparing a written proposal.
Plan the Access Hardening