What security checks should precede outsourced IT project access?
Before granting access, verify each supplier’s identity, confirm the project scope and assess the security of the people, devices and systems involved. Access should then be limited by role and duration, protected with multi-factor authentication, recorded through audit logs and removed when the work is complete.
Security checks should precede outsourced IT project access by establishing whether the supplier, its personnel, its working methods and the target environment are sufficiently controlled for the proposed work. The checks should cover governance, data protection, technical readiness and access conditions before any external party connects to business systems.
Confirm the supplier’s security responsibilities. The contract or statement of work should identify which party is responsible for each security task. This includes protecting business information, managing credentials, recording activity, reporting incidents, approving technical changes and preserving evidence. Vague wording can create gaps, particularly where the supplier relies on subcontractors or needs access to systems managed by another provider.
The agreement should also define:
- the systems and information relevant to the project;
- the supplier’s permitted methods of working;
- how security incidents and suspected data breaches will be reported;
- requirements for confidentiality and secure data handling;
- whether subcontractors may be used and how they will be controlled;
- how project records, temporary data and copies of information will be dealt with when the work ends.
Complete supplier due diligence. Before access is approved, assess the supplier’s security policies, relevant experience and internal controls. This does not mean accepting a policy document at face value. Ask how the controls operate in practice, who authorises technical work, how staff are trained and how security events are investigated. References from comparable projects, independent assurance reports or suitable certifications may support the assessment, but they should be considered alongside the actual risks of the proposed work.
If the project involves personal data, confidential commercial information or regulated records, confirm the legal basis for the arrangement and whether a data processing agreement is needed. Check where information will be stored, whether it will be transferred to another country and which employees or subcontractors can handle it. Data protection obligations should be reflected in the project documentation rather than left as an informal understanding.
Check the individuals involved. The organisation should know which roles require access and whether the assigned personnel have the competence to perform the work safely. Depending on the sensitivity of the systems, appropriate checks may include employment status, confidentiality commitments, security training and screening permitted by applicable law. Personal information gathered during screening should itself be handled carefully and retained only for a justified purpose.
It is also useful to establish who can provide technical approval and who can authorise a material change. A supplier’s engineer may be qualified to carry out a task without having authority to approve its business impact. Separating implementation from approval reduces the risk of an unreviewed configuration change affecting production systems.
Prepare the environment before connection. Record the current configuration, known dependencies and important business services before project work begins. Confirm that reliable backups exist where the work could affect data, applications or infrastructure, and check that restoration procedures have been tested sufficiently for the risk involved. A backup that cannot be restored is not an effective safeguard.
Review the environment for weaknesses that could complicate the project. Relevant checks may include:
- unsupported or unpatched operating systems and applications;
- unnecessary network routes, exposed management interfaces or inactive accounts;
- insecure protocols and shared credentials;
- inconsistent security settings across servers, endpoints or sites;
- dependencies on legacy equipment or undocumented integrations;
- monitoring gaps that would make unusual activity difficult to identify.
Where practical, separate project activity from unrelated systems using network segmentation, a controlled administration environment or a dedicated management route. This limits the consequences of an error and makes the supplier’s activity easier to distinguish from normal operational traffic.
Validate the access method. Do not send passwords through ordinary email or place credentials in shared documents. Use an approved secure method for issuing secrets, and ensure that credentials are unique to the task or individual rather than shared across a supplier’s team. Privileged credentials should be used only where the task requires them, with administrative actions attributable to a named person.
Test the access process in a non-production environment where possible. Confirm that the supplier can reach only the intended systems, that the required tools function correctly and that the organisation can see relevant activity. A short technical test can expose problems with routing, permissions, compatibility or monitoring before they affect live services.
Agree operational safeguards. Project work should follow an approved change process, including a description of the change, expected effect, implementation steps, validation checks and rollback method. Define when work may be performed, which business owner must approve it and what evidence must be supplied afterwards. These controls are about governing the work, not simply granting a connection.
Set clear conditions for handling sensitive information during troubleshooting. Screenshots, exported configurations, log files and diagnostic copies can contain credentials, personal data or commercially sensitive details. Agree where such material may be stored, who may view it and how it will be securely disposed of once it is no longer needed.
Document approval and review. Keep a record of the checks completed, outstanding risks, accepted exceptions and the person who approved access. Review the arrangement if the project scope changes, a different engineer becomes involved, a new system is added or a security incident occurs. Access approval should be treated as a controlled project decision, not a one-off technical administration task.
A managed IT provider such as S2 Technology Group can help a business structure these checks around its existing infrastructure and project controls. The essential principle is that access follows evidence: the organisation should understand the risk, approve the working method, prepare the environment and retain enough documentation to demonstrate that the connection was justified and controlled.
The depth of the security checks should match the level of access requested. Read-only access to a test system presents a different risk from privileged access to production infrastructure or systems containing personal data.
- Low-impact access: confirm the individual’s identity, role and approved systems.
- Sensitive access: require stronger authentication, tighter approval and closer review of the supplier’s handling procedures.
- Privileged production access: assess the business impact of changes, limit the permissions to the specific task and require clear evidence that the work was authorised.
This risk-based approach avoids applying identical controls to every project while ensuring that access to critical systems receives appropriate scrutiny. The assessment should be revisited if the supplier requests broader permissions or the project moves from testing into production.
