Glasses in front of a computer screen

How is an IT security audit carried out in a real company?

A computer security audit in a real company serves to determine the actual risk exposure of systems and data, beyond the theory. When done well, it connects technology, processes, and business, and is supported by frameworks such as ISO 27001 or GDPR to make investment decisions and prioritise actions. 

Why an audit is not just a formality

Many companies schedule audits out of contractual or regulatory obligation. The result is usually a report that gets filed away and barely changes working practices. An audit that adds value starts with clear questions: what would be the impact of a sales channel outage, a personal data leak, or an attack on the cloud environment? From there, the work is designed, not the other way around.

An IT security audit is a systematic review of how systems, networks, and data are protected against internal and external threats, comparing the actual situation with internal policies and standards such as ISO 27001. It includes both technical aspects (configurations, vulnerabilities, monitoring) and organisational aspects (policies, training, incident response, suppliers). It is not limited to an IT snapshot: it analyses how an incident would affect critical processes such as billing, production or customer service.

Three common confusions:

  • To identify an audit with an automatic vulnerability scan or a point-in-time pentest, when that's only part of the exercise.
  • To think it's an exclusive job for the systems team, with no involvement from business or other key areas.
  • Reduce it to a documentary requirement for ISO 27001, without using the results to adjust the security plan.

What does a CISO do before an audit?

Aims and scope

The first step is to agree with management on what you want to achieve. Common examples:

  • Prepare for ISO 27001 certification or recertification on the information security management system.
  • Assessing the risk in a specific environment, such as an e-commerce channel or a SaaS platform where billing is concentrated.
  • Responding to a customer or regulatory demand for assurances about the service's security.

With these objectives, the scope is defined: which sites, networks, applications, cloud environments, suppliers, and processes are to be reviewed. Here, it is decided, for example, whether to audit only the production environment or also development and pre-production, whether to include the own data centre and cloud infrastructure, or only part of it.

Typical errors in scope

  • Attempting to cover the entire organisation in a single, shallow audit, rather than starting with the most critical processes.
  • Exclude legacy systems, spreadsheets with sensitive data, or «temporary» applications that have remained in production for years.
  • Ignoring cloud environments contracted by departments without going through IT (shadow IT).

Inventory and context

To audit something, you must first know what exists. The minimum inventory includes:

  • Information assets: databases with customer, employee or supplier information, sensitive documentation, intellectual property.
  • Technology assets: servers, network devices, endpoints, containers, cloud services, and internal and external applications.
  • Business processes: how invoicing is done, how collections are managed, what steps an order follows, what systems are involved.

If the inventory is outdated or fragmented by equipment, risk analysis relies on an incomplete picture.

Auditor Selection

Depending on the objective, it will be decided whether the audit will be internal or external:

  • Internal audit, led by the security or internal audit department to assess controls and prepare formal audits.
  • External audit, carried out by a specialised company, necessary when seeking certification such as ISO 27001 or when a key client demands it.

In both cases, it is advisable to mix profiles:

  • Technicians: specialists in networks, systems, cloud and pentesting, capable of verifying configurations, vulnerabilities and evidence in detail.
  • GRC: individuals with experience in risk management, regulation and certification processes who know how to interpret ISO 27001 or ENS.

In medium and large organisations, a Security Operations Centre (SOC), whether internal or outsourced, also appears, providing information on monitoring and incident response.

How to carry out an IT security audit step-by-step

The names of the phases may vary by provider, but the logic is usually similar.

Audit plan

The auditor documents a plan that specifies:

  • Objectives and scope that have been agreed.
  • Reference standards, such as ISO 27001 for the security management system or the GDPR for personal data.
  • Calendar of activities, interviews and technical tests.
  • Contact persons in each area and availability expectations.

This plan is validated with the CISO and the relevant departments to avoid surprises, particularly during sensitive periods such as accounting close periods or migrations.

Information gathering

The audit begins by understanding how security is supposed to work:

  • Documentation: security policies, access control procedures, change management, incident management, contingency plans, training records.
  • Evidence: user listings, permission matrices, patch reports, backup logs, previous incident reports.
  • Interviews: Business leads, IT, Security, Legal, HR and, if applicable, SOC leads and key vendors.

The aim is to compare what is written with what is done.

Recurring errors

  • Generic policies downloaded from the internet, without adaptation to the company's reality.
  • Procedures that nobody follows because they are not integrated into tools and workflows.

Risk analysis

With the information on the table, the auditor identifies risks at three levels:

  • Technician: unpatched systems, unnecessary services exposed, weak passwords, default configurations.
  • Organisational: lack of segregation of duties, uncontrolled changes to production, absence of access or log reviews.
  • Compliance: Gap with respect to ISO 27001, GDPR, or internal policy requirements, for example, missing records of processing activities or impact analyses.

Each risk is assessed by impact (economic, operational, reputational or legal) and probability, using a defined scale, for example low, medium or high. This valuation is used for later prioritisation.

Technical field work

The technical part of the audit usually includes:

  • Vulnerability scans of the systems within scope, with manual review of relevant findings.
  • Penetration testing of web applications, APIs, internet-facing services and critical internal systems.
  • Configuration review of firewalls, routers, servers, cloud platforms, and authentication services.
  • Verification of endpoint protection (anti-malware, encryption, external device control) and network segmentation.

Some audits include controlled phishing exercises to measure exposure to human error or specific reviews of remote access and teleworking.

Operation assessment, SOC and contingency plan

The audit doesn't just focus on snapshots. It analyses how problems are detected and managed on a day-to-day basis:

  • Monitoring: what logs are generated, what is sent to the SIEM, what alerts are reviewed and how often, how incidents are documented.
  • Vulnerability and patch management: scan frequency, prioritisation criteria, closure times and evidence of changes.
  • Continuity and contingency: existence of an IT contingency plan, backup restoration tests, service outage simulations, RPO and RTO objectives.

A robust contingency plan includes failure scenarios, clear responsibilities, action procedures, and a testing schedule, not just a theoretical document.

Report, prioritisation, and action plan

The main output of an audit is the report. Its structure is usually divided into:

  • Executive Summary, outlining the most relevant risks, their business impact, and a priority map.
  • Technical detail for security equipment and systems, with a description of findings, evidence, associated risks, and concrete correction proposals.
  • Organisational improvement recommendations: policies to review, processes to adjust, training required, or changes in supplier relationships.

The real utility of the report depends on how it is translated into an action plan: actions, responsible parties, target dates, and closure criteria.

Tracking

Without follow-up, an audit remains a diagnosis. The cycle is closed when:

  • The implementation of the planned corrective actions is documented.
  • The risk analysis is updated with the new situation.
  • Follow-up audits, whether internal or external, are planned to verify that the achieved security level is maintained.

In environments with ISO 27001, periodic internal audits and external surveillance audits are integrated into the management system.

Recurring errors in companies

In practice, many problems detected by an audit are repeated from company to company:

  • Strategy
    • A lack of alignment between the audit and the risk appetite approved by management, which makes it difficult to justify investments.
    • Findings that are kept in a repository without assigned responsibilities or deadlines, meaning they reappear in the next audit.
  • Users
    • Generic security training, without adapting content to roles (support, development, business).
    • Sporadic or non-existent access audits, with users retaining permissions they no longer require.
  • Technology
    • Systems unpatched for months due to fear of production impact.
    • Insufficient network segmentation, allowing an attacker to move with ease once inside.
  • Suppliers
    • Contracts without detailed security clauses, incident notification, and service level recovery.
    • Lack of periodic reviews of critical suppliers, even if they handle sensitive data or key functions.
  • Operation
    • Mass generation of logs without the real capacity to analyse and correlate them.
    • Backups that are not tested with periodic restorations, so their reliability is unknown.

How to prepare a CISO to get the most out of them

A CISO who wants to get practical value from an audit usually works on three fronts:

Before

  • Review the asset inventory and information classification, at least for the processes to be audited.
  • Update core policies and procedures, identify gaps against ISO 27001 or similar frameworks, and decide what to address before the audit and what to leave as findings.
  • Explain to the teams the objective of the audit, the timeline, and the type of collaboration expected.

During

  • Facilitate the information and decisions the auditor needs to clarify risks and prioritise.
  • Provide business context to technical findings, so that priority is based not only on technical criticality, but also on impact.

After:

  • Convert the report into a concrete action plan, linked to the strategic security plan and budgets.
  • Use the findings as an argument to management to justify projects and resources.

Training for leading information security audits

To conduct audits effectively, technical and management knowledge are required. On the technical side, it is advisable to master vulnerability analysis, pentesting, system hardening, network and cloud environment security, monitoring, and incident response. On the governance side, experience in risk management, knowledge of ISO 27001, ENS, and GDPR, and practical experience in certification processes and relations with external auditors are needed.

The Master's Degree in Cybersecurity Online from IMMUNE Technology Institute focuses precisely on that hybrid profile, with content geared towards ethical hacking, vulnerability analysis, incident management, implementation of controls and preparation for frameworks like ISO 27001, all with practical cases and active teaching staff. It is a reasonable path for professionals already working in IT or security who want to take on CISO responsibilities or lead IT security audits in companies with a complex technical environment.

Related programmes


Miguel Rego avatar

Written by