An IT security audit assesses your organisation’s security against criteria agreed in advance. We examine the defined technical and organisational measures and document findings and their significance. The outcome is a clear report and prioritised improvement plan, rather than only automated scan output.Discuss an IT security assessmentExplore this service
SERVICE ASSESSMENT
Assess assessment scope, evidence and findings management systematically. After providing your email, see an answer-based overview, priorities and actions; a PDF will be sent to that address. This is not an independent audit conclusion.
Organisations needing an evidence-based security assessment against defined criteria and priorities for improvement.
Identify the audit purpose, systems, applicable criteria and people who can provide the required evidence.
Receive supported findings, a management summary, assessment limitations and a prioritised plan of recommendations.
An IT security audit systematically evaluates evidence against agreed security criteria. A technical assessment, an ISO/IEC 27001 internal audit and a legally required independent audit are different activities. The purpose, criteria, competence and impartiality requirements must be defined before commissioning the work.
The audit’s purpose determines what is assessed and what the result must support. Management may need an initial view of risk and investment priorities, while an IT team may need an assessment of particular access rights, configurations or processes. Before proposing scope, we ask which decision the report should inform and who will use it.
An internal audit, a technical review and a mandatory assessment submitted to an external body are different engagements. If a report is needed for a particular legal, contractual or certification purpose, we first check the requirements for the assessor, method and independence. This establishes whether the proposed service is suitable before evidence collection starts.
For each assessed area, we identify a criterion and the evidence used to evaluate it. The criterion may be a client-approved procedure, a specific agreed security requirement or a defined selection of standard provisions. Referencing ISO/IEC 27001 does not mean that the organisation has been assessed against the entire standard.
The report identifies scope and sampling: the departments, systems, period and documents examined, and those excluded. Unavailable evidence becomes an assessment limitation rather than an assumption presented as a confirmed finding. The areas below are possible scope elements, not a universal audit package automatically included for every client.
| Object | Criterion | Method | Sample | Limitation |
|---|---|---|---|---|
| Access management | Approved roles and access procedures | Compare accounts with authorisation records | Selected systems and accounts | Undisclosed systems are excluded |
| Updates | The organisation’s support requirements | Review versions, settings and work records | Components selected from the inventory | Reflects the state visible during assessment |
| Backups and recovery | Approved data-protection and recovery needs | Review configuration and test evidence | Selected backup jobs | A recovery exercise must be explicitly included |
| Processes | Client-approved security rules | Document review and interviews | Defined period and responsible people | A document alone does not prove implementation |
ISO/IEC 27001 describes requirements for an information security management system; its use in a particular assessment must be defined in the agreed scope.
Evidence comes from documents, explanations by responsible staff, system configurations and authorised technical checks. We compare these sources: for example, an account-closure procedure should be reflected in the selected operational records. An automated tool’s alert is assessed in context rather than copied into a finding simply because it carries a warning colour.
Technical actions are defined in advance, especially where they could affect live systems. We establish the responsible contact, appropriate access, secure transfer and evidence-handling arrangements. Reports contain the information needed to support conclusions, while sensitive technical evidence is delivered through a restricted-access channel.
The engagement must match the competence required and any potential conflict of interest. If we are assessing an environment we deployed or administer, that relationship is disclosed. Such a review can help the client address weaknesses, but it cannot automatically be represented as independent external assurance.
An internal auditor qualification does not itself confer certification-body status or authorisation for every specially regulated assessment. Where procurement terms require a particular certificate, registration or evidence of independence, suitability is checked before accepting that scope.
The report begins with a management summary explaining the assessed areas, the most significant weaknesses and the decisions needed. Its technical section links each finding to a criterion, asset, evidence and potential impact. Recommendations describe a corrective direction that the responsible employee can use to plan action.
Priorities reflect impact and the actual environment, rather than only a generic threat label. Unverified assumptions and assessment limitations are identified separately. We review factual accuracy with client representatives.
Each stage defines the work, your input and the result to check.
01
We establish how the report will be used and which requirements it must meet. Competence and impartiality conditions are checked, with potential conflicts of interest disclosed.
02
We define assets, criteria, sampling and permitted methods with the client. The result is a documented scope with responsible contacts and evidence-access arrangements.
03
We review records, interview responsible staff and perform the planned checks. Evidence is linked to criteria, while unavailable information is recorded as a limitation.
04
Client representatives review factual details and operational context. Incorrect assumptions are corrected, distinguishing an evidenced weakness from an unconfirmed signal.
05
We hand over conclusions, priorities and recommended corrective directions. The discussion helps the client assign owners and decide which findings need subsequent verification.
An audit reports on a defined scope and the evidence available during the assessment. It does not establish that no other vulnerabilities exist or that future incidents cannot occur. Excluded systems, limited sampling and unavailable data remain explicit boundaries of the conclusion.
This service does not issue an ISO certificate. Implementing recommendations, broader penetration testing or a follow-up assessment are not automatically included either: their assets, methods and verification outcomes need separate definition. The client can therefore distinguish the assessment itself from a subsequent remediation project.
We deliver the report, finding register and prioritised recommendations. The handover discussion identifies actions requiring a technical specialist, a process owner or management approval. The client assigns owners and deadlines according to operational constraints.
For each finding being addressed, we can define closure evidence such as a corrected configuration, an operating control process or a retest result. A follow-up review has its own scope: closing one finding does not automatically establish compliance across the organisation.
A sampled account retains access that is no longer needed after an employee changes role. The finding would identify the system, approved responsibilities, actual permissions and the criterion they fail to meet. The recommendation would cover reviewing that access and addressing the gap in the staff-change process.
This is a demonstration of a finding, not a client audit result. Its real-world priority would depend on the data and actions accessible through the account, so no universal risk score is assigned in advance.
| Factor | Why it matters | Information we need |
|---|---|---|
| Scope and criteria | The assessment purpose determines methods and report scope. | Purpose, criteria and external requirements. |
| Systems and locations | The number of assets and sampling affect the assessment. | List of systems and locations. |
| Evidence availability | Documentation and required methods affect the work involved. | Available documents and technical testing boundaries. |
Choose the service that matches the scope of your next task.
Assess a specific website and resolve agreed, verified vulnerabilities.
Monitor security events and escalate significant alerts through an agreed process.
LET’S TALK
State the assessment objective, systems involved and intended use of the report. We will review scope, criteria and the competence and independence required.
