Defined implementation
Know that a security alert reaches a person who acts on it.
The agreed data sources, alert rules, licensing, how long events are kept, and who responds are all set up. Each is tested with events you expect to see, then handed to a named owner with a runbook.
PricePrice fixed after a short scope call.
DeliveryThe proposal names the start date, the change windows and the completion date before anything is agreed.
What you receive · illustrative sample
Trace the alert all the way to its owner.
Illustrative alert validation record. Setup and testing are separate from a staffed monitoring service.
| Test | Expected path | Handover evidence |
|---|---|---|
| Agreed safe test event | Visible in the licensed security tool | Event and alert reference |
| Routing test | Notification reaches named reviewer | Acknowledgment recorded |
| Response ownership | Internal team or monitoring provider accepts | Escalation 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.
The business cannot say what its security tools actually watch, or who would look at an alert if one fired.
Scope considerations
- One Microsoft 365 tenant
- Supported Defender licensing
- A named alert reviewer exists
The defined work
Engagement scope.
- 01
The connected data sources are enumerated against the workloads the business actually runs, and the gaps are named.
- 02
Alert policies are configured for the agreed scenarios, with routing to a named reviewer rather than an unread mailbox.
- 03
Retention is set deliberately against the agreed requirement instead of left on defaults.
- 04
Expected test events are generated and traced end to end: raised, visible, routed, and acknowledged.
- 05
The named owner takes over a runbook that says what is watched, where alerts land, and what to do with them.
Acceptance
Completion has an agreed standard.
Done when expected test events are visible and routed, and the named owner accepts the runbook.
Every in-scope data source is connected and verified, or its gap is documented with a licensing or scoping reason
Expected test events are visible and routed to the named reviewer
Retention matches the agreed requirement
The response owner accepts the runbook
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
- Workloads and data sources in scope
- Licensing tier available for the connectors required
- Number of alert policies and routing rules
- Retention requirements beyond the defaults
Delivery calendar
The proposal names the start date, the change windows and the completion date before anything is agreed.
How engagements workScope & responsibilities
The full engagement boundary.
Review the exclusions, required client participation, change controls and operational handover for this engagement.
Exclusions
- Ongoing monitoring and alert response, which stay with the client or an MSP/SOC
- Emergency or same-day incident response
- Forensics or live breach containment
- SIEM migration or Sentinel build-out unless separately scoped
Client responsibilities
- Name the alert reviewer and response owner
- Provide licensing for the connectors in scope
- Approve the alert scenarios and change windows
Change and rollback method
- Configuration changes are staged in agreed windows; nothing is switched off while a replacement is unproven.
- Test events are generated against agreed test scenarios, never by weakening production controls.
- Rollback is the prior configuration state, captured before the first change.
Operational record and handover
- The data-source coverage register, connected and gaps alike
- The alert policy set and routing configuration, documented
- The test-event trace: raised, seen, routed, acknowledged
- The response runbook, accepted by its owner
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.
Set Up the Alerts