Choosing a new IT service provider looks like a purchase demand on paper. In practice, it is a decision on continuity, access to data, security, changeability and daily support for employees. Those who compare especially at a monthly price and a convincing presentation often discover important differences only after signing.
Start with the reason for reconsideration
First, explain why the current service is being reconsidered. Is it recurring failures, insufficient expertise, unclear invoices, lack of security, limited innovation or a contract that ends? Distince between incidents, structural shortcomings and expectations that have never been agreed in concrete terms.
An independent audit does not automatically lead to a supplier change. When the technical basis is repairable and the supplier cooperates openly, sharper agreements, active direction and re-examination can be a better route. Switching becomes more logical when quality, trust and cooperation are structurally inadequate.
An appropriate IT service provider can explain what it delivers, demonstrate how it works and pre-regulate how your organisation controls access, data, security, performance and any exit.
Show current IT services and dependencies
A good question requires a reliable starting point. Describe which services the current party provides, which systems and links are critical and what activities are carried out by other suppliers or internal employees. Also include management accounts, domains, certificates, backups, documentation and ownership of data.
Check that your organisation has access to critical management environments and that current documentation is available. A contract can promise transferability, while knowledge and practical access are entirely with one administrator.
- critical processes, applications and data streams
- cloud environments, networks, workplaces and telephony
- management accounts, licenses, domains and certificates
- links with SaaS, customers, suppliers and operational systems
- ongoing projects, technical debt and known security findings
- contracts, subcontractors, notice periods and exit agreements
Make must-haves and nice-to-haves keyable
A program of requirements should help suppliers to make a comparable and fair proposal. Describe both the desired solutions and the result that the organisation needs. "Good security" is too vague. A requirement for multifactor authentication, management accounts, logging, monitoring and periodic reporting is testable.
Split requirements in must-haves, heavy wishes and distinctive improvements. A supplier who cannot meet a must-have should not end up at the top of the list by means of a high commercial score.
- scope of management and support
- availability, accessibility and escalation
- architecture, standardisation and changeability
- information security, privacy and incident response
- backup, recovery targets and restore tests
- reporting, consultation, improvement cycle and evidence
- transition, data ownership and exit
- price model, indexation and additional work
Approach suppliers that fit the context
The largest or best known IT service provider is not automatically the best choice. Look at your experience with your size, sector, application landscape, opening times and risk profile. Ask how the supplier deals with specialist parts he does not supply himself.
Give each candidate the same information, planning and opportunity to ask questions. Put answers in central. This way you avoid that one supplier makes a more attractive but incomparable proposal based on additional background information.
Use a score matrix without false precision
A score matrix makes the balancing case followable. Give pre-weight to the topics that really make a difference for your organisation. Have several evaluators score independently first and then discuss the deviations. The difference between assessments often raises valuable questions.
An example distribution is 25 percent service and collaboration, 20 percent technology and architecture, 20 percent security and continuity, 15 percent transition and exit, 10 percent contract and governance and 10 percent total cost. Adjust the weighting to the organisation; treat must-haves as a gateway and not as a weighted wish.
- score only what is supported by reply, demonstration, reference or evidence
- record by criterion which means an insufficient, sufficient and strong score
- keep risks and exclusion grounds visible in addition to the overall score
- does not compensate for unnoticed technical or continuity risks
Key promises with evidence, scenarios and references
Ask candidates for concrete examples: a monthly report, an anonymised incident process, proof recovery tests, the management rights method and an example of a transition plan. Certificates may be relevant, but do not automatically tell how your environment is managed.
Call references yourself and use regular questions. Ask how the supplier responded to a serious incident, an error, an escalation or a departure. It is precisely then that the quality of cooperation becomes visible.
Identify responsibilities to be assessed in practice
The tender, service contract, processing agreements and SLA must be linked. Capture who is responsible for patches, monitoring, incidents, backups, restore tests, licenses, modifications and subcontractors. Also, make clear which reporting proves that work has been carried out.
An SLA with only response times says little about recovery or business impact. Therefore discuss scenarios: what happens when Microsoft 365 is unreachable, a firewall fails, ransomware is detected or critical application link stops?
- scope, exclusions and shared responsibilities
- availability and recovery targets per critical service
- reporting periods, escalation and crisis contacts
- audit law, evidence and follow-up of findings
- data ownership, retention periods and return
- liability, insurance and subcontractors
- Price changes, indexation and additional work
Design the exit before the cooperation starts
An exit arrangement is not a sign of mistrust. It shall prevent any future change from becoming unnecessarily risky or costly. Please specify the format in which data, configurations and documentation are transferred, the support available and the rates applicable.
Create a joint inventory, planning and risk analysis for the transition. Change management privileges checked, test critical services and ensure that backups and recovery procedures are validated before the final transfer. You can agree when the old supplier loses access and who checks it.
Rate the first hundred days as separate phase
The signature is not the end of the selection. Plan acceptance moments for documentation, monitoring, backup, management accounts, reporting and open migration points. Keep track of anomalies and agree when they are resolved.
After about three months, determine whether the practice is in line with the promises. This prevents temporary transition problems from becoming the new standard.
Checklist for a explanatory choice
Use these questions before the final decision and explicitly allow unanswered points to return as a risk.
- Has the reason for re-selection been confirmed in fact and in a management manner?
- Are critical processes, systems, connections and dependencies known?
- Are must-haves identifiable and exclusion grounds established in advance?
- Have candidates been assessed on the same information and criteria?
- Have security, recovery and incident response been tested with evidence?
- Have references been made about difficult situations and not just satisfaction?
- Do quote, contract, SLA and processor agreements connect?
- Are data, management rights, documentation, transition and exit practically regulated?
- Is it clear which residual risk management accept?
- Is the evaluation of the first hundred days already planned?
Sources and deepening
Based on official frameworks and practical implementation
The source pages provide the formal background. Kynexis Information Security translates this information into an executable approach for your organisation, sector and risk profile.
