Isolation has several independent layers
Build a map of what is shared, what is reserved and what has a separate recovery or change boundary. Request the evidence from the provider for the proposed environment. Do not infer security or performance from a product name alone.
| Layer | What to establish | Useful evidence |
|---|---|---|
| Compute | Which CPU and memory resources are available, reserved or contended? | Provisioning specification and representative workload observations. |
| Storage | Which limits, maintenance events and failure domains are shared? | Storage topology, measured latency and recovery procedure. |
| Network | Which paths, limits and filtering controls apply? | Traffic flow diagram and controlled connectivity tests. |
| Administration | Who can reach each component and approve changes? | Role matrix, privileged access process and relevant audit records. |
| Recovery | Which failures can affect multiple services together? | Dependency map and a demonstrated restoration plan. |
Match separation to the operational problem
A shared environment may be sufficient for a bounded pilot or an ancillary service where its resource and access boundaries satisfy the requirement. Evaluate the service in its actual hosting tier, including the provider limits and incident process. A good result in an unrestricted demonstration does not establish the same result in the contracted environment.
Stronger separation deserves evaluation when workload contention, restricted change windows or an unacceptable common failure domain is a concrete concern. Record which separation addresses that concern. Moving to a dedicated machine alone does not resolve a shared upstream connection or an undocumented administration path.
Test the boundary rather than the adjective
Use a representative workload to observe response time and resource use across a meaningful operating window. Include routine jobs such as reporting and backups. Compare repeated measurements, not a single fast demonstration. Any agreed performance target should name the workload, measurement point and conditions.
For access isolation, inspect the proposed roles and test only authorised paths in a controlled environment. Recovery tests should establish which services can be restored independently and which require a provider intervention. These are proposed evaluation checks, not claims that any particular hosting offer has passed them.
An example decision and handover record
Illustrative scenario: a brokerage sees reporting slowdowns during a scheduled maintenance task. Separating the reporting workload may solve the specific contention without redesigning the entire platform. Measure the baseline first, change one boundary and repeat the same observation before concluding that isolation helped.
The decision record should contain the identified risk, the chosen boundary, the measured evidence and the work still shared. Use the hosting checklist to connect those findings to the MT4 or MT5 deployment scope. Keep responsibilities explicit after handover so isolation does not become an untested assumption.