Identify the administrative boundaries
Draw the boundary between client-facing access, platform administration, hosting control and integration services. List the organisations and individuals who can modify each layer. For a hosted or White Label arrangement, ask which controls are managed by the provider and which evidence the brokerage can obtain.
Separate everyday operator permissions from exceptional administration. Use individual accounts and stronger authentication where the relevant systems support it. Record the approval and revocation process; do not assume that removing a person from one portal also removes every server or integration credential.
Apply supported hardening without breaking the service
- Maintain an inventory of supported operating-system and application versions.
- Restrict exposed services to the access actually required by the deployment.
- Separate administrative access from public client access where supported.
- Review the permissions of service accounts and integration processes.
- Stage maintenance and configuration changes with a recovery path.
Security changes must respect vendor requirements and tested dependencies. A copied firewall recipe or a blanket service-disable command can interrupt legitimate workflows. Validate the proposed control in the intended environment before applying it to production.
Preserve an investigation trail without collecting secrets
Identify the events needed to investigate access and configuration changes. Preserve the actor, time, relevant object and outcome, with enough context to connect events across systems. Restrict access to the records and protect their integrity according to the environment's requirements.
Avoid placing reusable credentials, full authentication tokens or unnecessary client data in routine logs. Investigators should have a defined route to the evidence they need without turning every diagnostic export into a copy of sensitive production information. Review what third-party support staff receive during troubleshooting.
Test revocation and recovery as part of readiness
Illustrative example: an external integration is retired, but its service account and firewall allowance remain active. An access review identifies both remnants and assigns their removal through the approved change process. The review is stronger when it checks actual permissions rather than only the current staff list.
Include credential revocation, restoration access and emergency escalation in a staged exercise. Confirm that protected backups remain accessible to the authorised recovery team after a primary-host failure. For an MT4 service or MT5 deployment, request a clear responsibility matrix instead of treating “managed hosting” as a complete statement of security ownership.
Define security responsibilities precisely
Does managed hosting cover platform permissions automatically?
Ask for the actual responsibility split. Hosting operations, platform administration and integration permissions can belong to different teams. Identify who reviews and revokes access at each layer, and what evidence the brokerage receives. The service label alone cannot establish those controls.
Should a security review change live settings immediately?
Begin with a read-only inventory and an agreed assessment scope. Put proposed modifications through the relevant change procedure, respecting vendor requirements and recovery dependencies. An observation can be important without authorising an untested configuration change during production operation.