Onboarding & Engagement Model
Structured intake. Defined scope. No surprises after work begins.
Every engagement starts with a structured onboarding phase. This is not a formality — it is the process by which we establish what your environment looks like, what the target state is, what risks exist, and what the boundaries of our responsibility are. Skipping or compressing this phase produces environments that are difficult to maintain and impossible to audit.
Phase 1 — Discovery and Assessment
Before any configuration changes are made, we document the existing environment. Output: a written discovery summary provided to the client. This becomes the baseline against which all changes are measured.
- Inventory of hardware, operating systems, and installed services
- Network topology mapped (logical and physical where possible)
- Existing access controls and account structure reviewed
- Current backup posture and any identified gaps
- Compliance or regulatory constraints identified and recorded
Phase 2 — Scope Definition
Based on discovery findings, we produce a written scope document. The scope document requires client sign-off before work begins. Changes to scope are handled through a written change request process — no verbal approvals, no undocumented scope creep.
- Services to be delivered (from the defined service catalogue)
- Explicit exclusions — what is outside scope
- Assumptions that the scope depends on
- Dependencies on third-party software or hardware (with associated costs disclosed)
- Timeline and access requirements
Phase 3 — Implementation
Work is executed against the signed scope. All changes are logged. No production changes are made outside agreed maintenance windows without prior approval.
- All changes are logged throughout implementation
- No production changes outside agreed maintenance windows without prior written approval
- Client is notified of any findings that affect the original scope or timeline
- Interim documentation is updated as work progresses
Phase 4 — Validation and Handover
At the conclusion of onboarding, delivered configuration is validated against the scope document. Outstanding items, deferred work, or documented exceptions are listed explicitly — not left implicit.
Client receives a handover package containing:
- Network diagram
- Asset inventory
- Access boundary summary
- Backup procedure documentation
- Change log from the implementation phase
- Explicit list of any outstanding items or documented exceptions
Ongoing Managed Services
After onboarding, managed services operate under a defined maintenance model.
- Patch management applied on a documented schedule with defined maintenance windows
- Change requests submitted in writing and approved before execution
- Monitoring alerts triaged according to a documented escalation path
- Periodic reviews available to assess posture and adjust scope
What We Expect From Clients
A managed service relationship is not one-directional. The following are expectations, not suggestions.
- Respond to documented change requests within agreed timeframes
- Notify us of hardware changes, new users, or application additions before they happen
- Participate in scoping discussions honestly — undisclosed risks affect the quality of delivered security
- Respect change control — unilateral changes to managed systems may void our ability to support them