What Does an IT Security Audit Include?

What does an IT security audit include? A business security audit has two distinct parts: an organisational review of responsibilities, access, backups and incident response, and a technical review of system settings, vulnerabilities and code. The price depends on the extent of the systems being checked and the depth of the work: our automated security check costs €89–890 depending on the scope, while a manual expert audit starts from €3,500. First establish which part you need and what evidence you expect, because a website assessment, a review of business security management and certification are separate commissions with different results.

Imagine that, before signing a contract, a client sends you a requirement for a security audit, with an attachment asking about both employee access rights and technical system testing. Simply forwarding the requirement to your developer is not enough: you need to agree whether the client expects a website report, documented business processes or a certificate from an independent body, and which systems or business activities that assurance must cover. We recommend keeping the exact wording of the request and establishing its purpose before choosing a provider and accepting a quotation.

What does an IT security audit include? Two types of work

The two parts answer different questions. The organisational part asks how the business makes and implements security decisions; the technical part asks how a particular system works and whether its protection can be bypassed. The same subject therefore looks quite different in each: when reviewing access procedures, an auditor asks to see who approves an employee’s permissions and how they are revoked, whereas in application testing they use an ordinary account to try actions that account is not allowed to perform. The two sets of results are worth reading together, but neither replaces the other: a sound access policy does not prove that an application enforces it, and a secure application does not prove that anyone has closed a former employee’s account.

The word ‘audit’ alone therefore tells you little in a brief. We recommend adding two things: the criteria against which the work will be assessed and the evidence you expect in the report. For a vulnerability assessment, that means prioritised findings; for penetration testing, a specific protection mechanism or operational restriction that the tester will try to bypass; and for an organisational compliance audit, a set of requirements against which documents and everyday practice will be compared.

If you choose only an initial assessment of weaknesses, describe the result as such rather than as certification, and agree in the brief who will read the document and what decision they need to make. For certification, it matters who will issue the assurance: ISO does not certify businesses itself, and it describes certification as written assurance from an independent body that specified requirements have been met. In the same explanation, ISO states that accreditation confirms a certification body’s competence but is not compulsory; claiming that only an accredited body may certify would therefore be inaccurate. If your client requires accredited certification, establish that condition before signing the contract and check the chosen body’s accreditation, so you do not end up with assurance the client has not agreed to accept.

Our service is technical testing of web systems, and we can help prepare security policies for the organisational part. However, we do not certify businesses or run your information security management system (ISMS) for you, and that boundary is worth recording in the brief too. If the assignment includes both website testing and a review of business management, agree who will prepare the technical evidence, who will compare it with the chosen requirements and who is responsible for the final assessment. Otherwise, you may expect us to assess a management process while expecting an organisational auditor to perform testing you have not commissioned. The organisational part is usually carried out by an information security management consultant or an ISO/IEC 27001 auditor, while a certification body issues the certificate.

The organisational part: compare documents with practice

A policy can promise anything on paper. In the organisational review, check whether its commitments have someone responsible for them, the necessary resources and evidence of implementation, and whether action is planned for the problems identified in the risk assessment; ENISA’s guide for small and medium-sized businesses covers management responsibility, employee involvement and training, security policies, supplier management, access protection and an incident response plan. Alongside discussions with management and employees, examine documents and specific examples of work. This allows the assessment to distinguish intended procedures from their implementation and identify evidence the auditor could not obtain and which still needs to be prepared.

For access, a good auditor looks not only at how accounts are granted but also at how they are closed, whether multi-factor authentication is used and what permissions suppliers have. Include an employee departure or a change of supplier among the examples checked: these are precisely where accounts tend to be forgotten. Backups are similar, because ‘we make copies’ tells you little. A backup that nobody has ever restored may prove incomplete during an incident, and you only discover this when the website is already down. System and device inventories need people responsible for them, event logs need a review procedure, and the incident response plan needs a named person who makes decisions and communicates with those involved. Otherwise, the plan remains a document nobody follows during an incident.

You can use ISO/IEC 27001:2022 as the criteria: it sets requirements for an information security management system. Here, ‘system’ means management, not just the application being tested; BSI’s explanation of the standard identifies 93 information security controls across four themes: organisational, people, physical and technological. Agree which requirements the audit will assess and what evidence it will use. A reference to the standard in a quotation does not tell you whether you are commissioning a management system assessment or only technical testing whose results will later inform a broader audit; put that choice in writing before work starts.

Another basis is CIS Controls v8.1, with 18 groups of controls, covering areas from enterprise asset inventory to penetration testing and comprising 153 safeguards in total. CIS describes CIS Implementation Group 1 (IG1) as essential cyber hygiene with 56 safeguards, so specify the chosen group in the brief as well as the framework’s name. Ask for the report to link each requirement assessed to the evidence received and the weakness found, so that after fixes you can check the same condition rather than compare two general assessments.

When the law requires a security audit

There is no single audit statute for every English-language reader. Under Directive (EU) 2022/2555 (NIS2), a company is not an ‘essential’ or ‘important’ entity merely because it exists: the categories depend on the sectors in Annexes I and II and largely on the entity’s size. Each Member State designates its own competent authority. Where NIS2 has been transposed and your company is in scope, the directive does not impose a general obligation to commission periodic external audits. It gives the competent authority powers to subject essential entities to regular and targeted security audits by an independent body or a competent authority, and to ad hoc audits, including where a significant incident or an infringement justifies one. For important entities, the authority acts where necessary on evidence, an indication or information of alleged non-compliance, and its audit power covers targeted security audits by an independent body or a competent authority, not regular audits. The audited entity pays for a targeted audit carried out by an independent body, unless the authority decides otherwise in a duly substantiated case. The authority may ask for evidence such as the results of a security audit by a qualified auditor. If the authority orders the entity to remedy deficiencies or implement an audit’s recommendations within a reasonable deadline, the entity is responsible for carrying out that order.

There is no single self-assessment calendar for every English-language company. Where NIS2 applies, Article 21(2)(f) requires policies and procedures to assess whether cybersecurity measures work, without setting an interval or filing date. Annex point 6.5 of Commission Implementing Regulation (EU) 2024/2690 applies only to the digital and trust service providers listed in Article 1 that fall within NIS2’s scope. It requires a security-testing policy and procedures, with each provider determining the need, scope, frequency and type of tests from its own risk assessment, documenting the results and taking mitigating action on critical findings. Recital 15 describes penetration testing as one possible method and says tests may take place at set-up or after a significant change; it does not mandate penetration testing before commissioning or on a fixed cycle. When you receive an offer to carry out a ‘mandatory audit’, ask the provider to identify the specific obligation and your status, so that preparing a self-assessment where national law requires one and carrying out an external audit ordered by a supervisory authority are not treated as a single commission.

The technical part: from public addresses to code

In the technical brief, specify the public addresses, DNS records, exposed services and TLS settings, as well as the server or cloud configuration, web applications and source code you authorise the provider to examine. For each part, state whether the provider will have access to the settings or will assess only what is visible externally, because these are different tasks. NIST’s classification of security testing techniques separates document, log and configuration reviews from target identification and analysis, and from vulnerability validation. You can use that distinction to describe the chosen methods and expected results more precisely in the quotation.

For web applications, OWASP Top 10:2025 provides a common language: ten risk categories, the first two being broken access control and security misconfiguration. The list does not test anything by itself, so a good auditor turns each category into a question about your application: for access control, that means attempting actions belonging to one role using another role’s account; for insecure design, it means choosing a business process whose rules someone could bypass. Add the extent of testing to the OWASP reference, so both parties understand which functions and user roles this assignment actually covers.

For email, include an assessment of SPF, DKIM and DMARC settings, linking the task to the systems your business uses to send messages: since 1 February 2024, Google’s sender requirements have required all senders to Gmail accounts to configure SPF or DKIM, while those sending more than 5,000 messages a day must configure SPF, DKIM and DMARC. The DMARC policy may be ‘none’, but for direct messages, the domain in the From field must align with the SPF or DKIM domain. Ask for both the settings and your sending routes to be assessed, rather than merely ticking a box to confirm that domain records exist.

The most common finding in our audits is missing updates to PHP, the CMS core and software frameworks. We therefore recommend including a review of the versions, plugins and dependencies in use in the technical brief, and asking each finding to identify the specific component and required action, so your developer receives an actionable task rather than a general warning about an outdated website. If your main concern is what users are allowed to do in the system, a version review is not enough: access control and business logic testing are also needed. In our experience, there have been critical flaws that allowed any user to gain administrator rights, and fixing them ended in a complete rewrite of the system’s core; a version review would not have found such a flaw.

What a user is allowed to do is a different question from which versions are installed, and each needs its own evidence in the report. NIST defines vulnerability scanning as a technique for identifying hosts, their attributes and associated vulnerabilities, while scanning is one stage of the technical work in our automated security check. NIST’s explanation of penetration testing describes the simulation of real attacks to seek ways of bypassing protection, often including combinations of vulnerabilities that enable broader access. We discuss choosing the testing in more detail in our article about penetration testing. For the audit brief here, the key is to specify which weaknesses the provider will only look for, which they will attempt to demonstrate can be exploited within agreed boundaries, and which actions they will deliberately leave outside the work.

The IT security audit process: from brief to retest

Start with a written description of the audit scope naming the systems, applications, addresses and user roles to be tested, and clearly stating what this commission will not cover. Add the objective and working boundaries: which actions you authorise, which environment they will take place in, who can stop testing and whom to contact if something unexpected happens. For an ordering system, for example, agree separately how to test actions that would otherwise create a real order. Your maintenance provider should also read this agreement, so authorised actions, access and contacts are agreed before technical work begins.

Before work starts, prepare the documents and people needed for discussions to the extent required by the brief: for the organisational part, policies, examples of access being granted, backup restore records and the incident response plan; for the technical part, a system description and agreed access, also noting anything you do not yet have. If you are testing a copy, record how it differs from the system in everyday use and agree how the report will reflect this. The reader should later be able to understand which environment the results apply to and which questions remain open because documents, access or the relevant function were unavailable. Agree specific testing times and communication arrangements for technical work, and set a deadline for colleagues to submit clarifications for the document review, so the result clearly distinguishes what has been checked from what remains unconfirmed.

If the provider discovers a significant problem during the work, ask them to report it through the agreed procedure while the rest of the work continues, without waiting for the full report’s handover date. Also agree who decides whether testing should continue in that area and how permissions or restrictions received will be recorded, because those decisions will be needed to explain how far the particular finding could be verified.

Allow time for fixes in the schedule

An audit using our system takes a few days, while the manual audit work itself takes 1–3 weeks depending on the audit scope, and there may be a wait before it starts depending on the auditor’s workload. The service page gives an overall completion range of 1–60 days, so do not treat these descriptions as a single guaranteed deadline. Agree the start date, report handover and retest before commissioning the work. If a client or procurement process sets your deadline, also allow time to review and fix findings and for your team to answer questions, because the date testing finishes and the date by which you want weaknesses resolved are separate planning points.

Our manual expert audit offer includes a retest within 30 days after fixes. To make meaningful use of it, agree at report handover who will fix each finding, who will notify the provider when the work is complete and what evidence the provider will recheck. Agree the extent and cost of the fixes separately, because the audit price is not an agreement covering all subsequent development. Your own team can make the fixes and we will check them afterwards, or you can commission us to do them as separate work, which we estimate after the report. Ask the retest report to distinguish fixed weaknesses from those deferred or not yet rechecked, and to identify the system state used, so your team and the report’s recipient have one clear answer for each original finding.

What to request in the audit report

Ask for the report to begin with an overview management can understand, explaining the assessment’s purpose, the systems covered and the most important findings, so decisions about work and resources can be made without reading all the technical material. Ask for the limitations of the work to be stated there too. If source code was unavailable or a user role was not examined, ask for this to be stated explicitly rather than leaving readers to guess what a brief assessment of the system’s condition means. Judge the overview by whether your manager can use it to identify the next decision, the person responsible and a question that remains unanswered.

For every technical finding, request its location in the system, the circumstances in which it was found, the user role used, steps to reproduce the action and evidence of the result. For an organisational nonconformity, ask for the document or example of work supporting the assessment alongside the reference to the requirement. A recommendation must make clear exactly what needs to change, so narrow ‘sort out access’ down to the specific permissions and function your developer must change, and state the expected behaviour after the fix. The report can then be used both to hand over the task and to check it later, without each subsequent reader having to reinterpret the auditor’s intention.

If the report uses the Common Vulnerability Scoring System (CVSS), ask for the version too: FIRST publishes CVSS, including version 4.0, whose severity rating scale uses ‘none’ (0.0), ‘low’ (0.1–3.9), ‘medium’ (4.0–6.9), ‘high’ (7.0–8.9) and ‘critical’ (9.0–10.0); using these qualitative labels is optional. Alongside the score, request the reasoning and an explanation of its relevance to your business operations, such as which activity or dataset the finding affects and why the recommended order of fixes was chosen. This allows priorities to be discussed using the circumstances described, not just the number.

We use our experience with such critical flaws to insist on a clear description of consequences, rather than to claim that every website needs rebuilding: the report must distinguish a specific fix from a problem whose solution requires reconsidering how the system fundamentally works. If the report recommends extensive reworking, ask to see which evidence supports that recommendation, what can be fixed separately and what question will remain unresolved if the business chooses only part of the proposed work.

Request the scanner’s raw results file as an appendix if the technical team needs it, but tie acceptance of the report to the evidence, priorities and actionable recommendations you expect under your brief; do not use the number of lines as a measure of quality. Ask the provider to explain one finding from start to finish: how it was detected, what the result proves, how it affects your system and how they will check after changes that it has been resolved. Also ask them to identify anything in that conclusion that remains an assumption. This review gives you a concrete basis for accepting the report and allocating subsequent work.

Why audit prices vary so much

Prices differ mainly because offers cover different numbers of systems and different depths of work: automated scanning and version reviews cost hundreds of euros, while manual access control and business logic testing, secure code review and a retest require days of expert work. The automated security check in our website security audit service costs €89–890 depending on the scope and is intended for WordPress, Laravel, Drupal, Joomla and Moodle systems. The offer includes automated vulnerability scanning, version, plugin and dependency checks, assessment of configuration and server settings, and a report with findings and priorities. Use that content when comparing the price with another offer, and clarify which of your installations will be checked. Treat the lower end of the range in relation to the agreed scope, so you do not apply the price of checking one website to all the business’s systems before the provider has assessed their extent.

Our manual expert audit starts from €3,500 and includes manual assessment against OWASP Top 10, access control and business logic testing to identify bypasses, secure code review and authorised penetration testing. Secure code review is available for Laravel, WordPress and custom-built solutions. In the report, we rank findings by actual risk and add a recommended fix to each; the offer also includes a retest after fixes. ‘Starts from’ still applies even if your system has only one public address, because the functions, roles and code to be tested still need to be agreed for the quotation.

A full check using our system usually costs €500–800. This is the amount we see most often within the automated security check price range, rather than a separate price for a combined assessment of business management, all systems and certification. Relate the word ‘full’ to the specific technical scope we have agreed. For most websites, we recommend a regular automated security check that can be repeated frequently, with a manual expert audit when the system processes payments or personal data, or is business-critical, because only a person can find access rights flaws and ways to bypass business logic. In practice, regular automated security checks and a manual audit once a year work well.

This distinction also helps with budgeting: if you need answers about website components and settings, request a quotation for that task. If the main question concerns bypassing user permissions or business rules, include the appropriate manual tests and allow the provider to estimate that work separately.

To compare offers, prepare the same description of systems, applications and user roles, and, if the organisational part is also needed, business locations. Then ask providers to list automated and manual activities separately. Imagine one quotation covering only the public website and another covering the same website plus the customer portal, administration and source code: establish the boundaries of each offer before comparing totals. For each part, also record the access needed, the chosen compliance criteria and the report’s recipient. This gives the provider a concrete basis for the quotation and gives you a way to spot an omitted task.

Clarify separately whether the price includes explaining findings to your developer, linking them to the chosen standard’s requirements and a retest, as well as where the audit work ends and development of fixes begins. We also recommend making a decision about remedying the weaknesses found as part of audit budgeting. If prices still differ substantially between offers covering the same work, ask providers to explain their work and its boundaries using one specific function, such as changing a user’s access, rather than additional service names. You can then choose based on a concrete result and responsibility, without relying on a promise of comprehensive security.

When a business needs a security audit

We recommend commissioning an audit when the business needs to make a specific security decision or provide verifiable assurance, and stating at the outset whether that decision concerns management, the technical condition or both. If NIS2 is the reason, first establish your status and the applicable requirements, also using our article about NIS2 and its scope, and then formulate the brief. The order matters: establish whether the requirements apply and what assurance is needed before choosing a service, so commissioning a technical report does not become your only answer to a question that also requires an assessment of business responsibilities and processes. If the website has no user accounts, payments or personal data processing, and nobody requires assurance, an extensive audit is usually unnecessary: install updates first, and an automated security check is sufficient.

If an insurer or client requests the assessment, ask them to clarify the expected result and give the provider the actual wording of the requirement. For example, separate a question about employee training or a backup restore test from a requirement to test application access rights, and prepare appropriate evidence for the answers. If a supplier questionnaire requires assurance about a broader security process than your technical audit covers, agree the additional information with the client and appoint someone in your business to collect it, rather than broadening the meaning of the technical report. Also clarify whether the recipient expects the report itself, answers to specific questions or another form of assurance, and by what deadline.

For procurement, keep the required assessment type and provider qualification conditions exactly as the contracting authority has worded them, and resolve uncertainties before requesting a price, so the offer does not need rewriting after work begins. We examine the choice in more detail in our article about the security assessment required in procurement. To prepare the technical brief, you can send us the wording of the requirement and a system description. Include the submission date, available documentation and who on your side will make fixes, because the discussion about delivery must cover not only preparing the report but also your team’s ability to act on its results by the required date.

After an incident and between planned assessments

After an incident, we recommend shaping the audit brief around the specific unanswered question: whether a fix resolves the identified problem, whether a similar access flaw should be sought in another function, and how the business will check that the relevant procedure is followed in future. Give the provider a description of the known events and distinguish confirmed facts from assumptions. If you want to establish how the incident unfolded, name that work separately too and agree its result, rather than assuming a general website audit will automatically answer every question about the incident. Keep the fixes being checked linked to the original findings, so after changes you can say exactly which problem you retested and how.

Our clients usually commission an audit once or twice a year; this is an observation from our experience, rather than an interval prescribed for all businesses. In your plan, we recommend recording not only the next date but also the changes that will trigger another review of the extent of testing, such as a new user role, a rewritten access function or a replacement supplier with system permissions. Ask the responsible person to compare these changes with the previous audit scope and propose the specific part to be tested. Keep unresolved findings from the previous report in the next brief, together with decisions to defer them, so the new assessment starts from the known situation.