What information does an IT security consultancy need before starting?

An IT security consultancy needs more than a general description of the organisation. Before work begins, it usually needs authorised access arrangements, reliable evidence, clear decision-making contacts and agreed rules for how assessment activities will be carried out. This allows the consultant to distinguish confirmed findings from assumptions and produce advice that can be acted on safely.

Named contacts and decision-making authority

The consultancy should know who is responsible for approving the engagement, who can answer technical questions and who owns the relevant business processes. These may be different people. A useful contact list can include an executive sponsor, an internal or outsourced IT lead, a data protection contact, facilities or site representatives, and owners of important applications.

It should also be clear who can approve changes to scope, provide access to third-party platforms and accept any operational risk associated with testing. Without this authority, an assessment can be delayed while basic permissions are established or produce recommendations that no one is empowered to implement.

Written permission and rules of engagement

Any activity that involves scanning, configuration review, simulated attacks, social engineering or access to sensitive records should be covered by written authorisation. The rules of engagement should define:

• which environments and accounts may be assessed;
• which techniques are permitted and which are excluded;
• how potentially disruptive tests will be controlled;
• how suspected incidents or serious weaknesses will be reported;
• what evidence may be copied, stored or shared; and
• how external providers will be involved where their permission is required.

This is not merely administrative. Clear authorisation protects the organisation, the consultancy and relevant suppliers from misunderstandings about legitimate testing.

Technical and documentary evidence

Where available, the consultant may request read-only access, reports or documents such as:

• network and cloud architecture diagrams;
• asset, account and privileged-access records;
• configuration standards and change records;
• security policies, procedures and staff guidance;
• previous audit, penetration-test and vulnerability reports;
• records of security incidents, near misses and remedial actions;
• backup, recovery and continuity test results; and
• relevant contracts, service descriptions and assurance reports from technology providers.

The purpose is to compare documented controls with their actual operation. For example, a policy may require regular access reviews, while access records may show that reviews are incomplete or not formally evidenced. Both the written requirement and the operational evidence are needed to assess the control accurately.

Access arrangements and safe evidence handling

The consultancy will need to agree how information is supplied and how its own access is managed. This can include named accounts rather than shared credentials, suitable authentication, approved remote-access methods, permission levels, logging, and a process for removing access when the work ends. It should also know whether evidence must remain within a particular location or platform.

Before files are shared, the organisation should identify information that requires special handling, such as personal data, confidential commercial material, credentials, payment information or sensitive client records. Redaction, secure transfer, retention and deletion requirements should be agreed at the outset. A consultant should not need unrestricted access to every record simply because some records are relevant to the assessment.

Operational boundaries

The consultant needs to understand which activities could affect essential operations and which periods or environments must be avoided. This includes identifying production systems, test environments, maintenance dependencies, fragile legacy components and processes that cannot tolerate interruption. The resulting boundaries should be recorded in the engagement plan rather than left to informal assumptions.

It is also useful to explain how the organisation handles changes during the assessment. Planned upgrades, migrations, restructures or supplier changes can alter the evidence and may require the scope or findings to be reviewed before the final report is issued.

Agreed outputs and acceptance criteria

Before starting, both parties should agree what the work will produce and how findings will be prioritised. A useful brief specifies whether the organisation expects a risk assessment, control review, remediation roadmap, technical report, management summary, workshop or follow-up validation. It should also define how severity, business impact, likelihood and implementation effort will be considered.

This prevents a technically detailed report from being delivered when decision-makers need a prioritised improvement plan, or a high-level review from being commissioned when engineers require configuration-level evidence. It also establishes who will review factual accuracy and how disagreements about findings will be handled.

What happens if information is missing?

Incomplete records should not automatically prevent an assessment. The consultancy can record gaps as findings, test assumptions, use interviews and identify evidence that should be created. However, missing information should be disclosed because it affects confidence in the conclusions. A well-prepared organisation therefore provides what it can, labels documents that may be out of date and identifies areas where the consultant must validate information independently.

For a business engaging S2 Technology Group, this preparation provides a structured starting point for IT security consultancy. The aim is not to assemble perfect documentation before asking for help, but to make permissions, evidence, responsibilities and practical boundaries clear enough for the assessment to produce dependable recommendations.