IT Security Audit - Why Your Company Needs One

Why an audit is essential

Most business leaders avoid the subject of IT security audits, trusting that "nobody is going to manage to hack us". That approach is not merely naive — it is expensive. GlobalData research from 2024 shows that the average cost of a data breach in Poland is around PLN 850,000, and that in large organisations it exceeds PLN 2 million. At the same time, 60 per cent of security incidents could have been prevented or contained through regular auditing and penetration testing.

What an audit is and what it is for

An IT security audit is a systematic, comprehensive assessment of how well an organisation's information systems are protected. It identifies threats, vulnerabilities and weaknesses across infrastructure, applications and security procedures. Done properly, an audit gives management a clear picture of the real level of security, makes it possible to plan investment in protection, and provides evidence of due diligence should an incident occur later. That matters particularly in the context of legal requirements such as GDPR and NIS2, which require organisations to demonstrate that they are taking appropriate technical and organisational measures to protect data.

60 per cent of security incidents could be prevented through regular audits.

There are many types of security audit, each with a different scope and purpose.

When an audit is mandatory — four legal regimes

The question "do we have to?" comes up far more often than "is it worth it?". The answer depends on which regime the organisation falls under — and in practice many organisations fall under several at once.

The National Interoperability Framework (KRI) — bodies performing public tasks. The applicable instrument is the Council of Ministers Regulation of 21 May 2024 (Journal of Laws 2024 item 773), which on 23 May 2024 replaced the 2012 regulation. The audit obligation now sits in §19(2)(14): a periodic internal audit of information security at least once a year. That is the shortest cycle of all four regimes. Be wary of material circulating online — a great deal of it still cites §20 of the repealed regulation and states a frequency of "once every two years".

The KSC Act — essential entities. Following the amendment in force from 3 April 2026, an essential entity must carry out an audit of the security of its information system at its own expense, at least once every 3 years, counted from the date the report on the previous audit was signed. A copy of the report must be submitted to the competent authority within 3 working days of receiving it. The authority may also, at any time, order an essential entity to undergo an external audit; for an important entity, it may do so in the event of a significant incident or another breach of the act.

DORA — the financial sector. Regulation (EU) 2022/2554, applicable from 17 January 2025, requires annual testing of ICT systems and applications supporting critical or important functions and, for designated entities, advanced threat-led penetration testing (TLPT) at least once every three years. Where internal testers are used, at least every third test must be performed by an external party.

GDPR — all controllers and processors. Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing". GDPR deliberately sets no frequency — the obligation is risk-based. That does not make it soft: in June 2026 the Supreme Administrative Court dismissed Virgin Mobile's cassation appeal, upholding a fine of PLN 1,599,395 and confirming that the obligation to test regularly has rested on controllers since 25 May 2018.

What the KSC amendment of 3 April 2026 changed

The amendment to the KSC Act (Journal of Laws 2026 item 252), implementing the NIS-2 Directive, reshaped the audit rules in four places.

A longer cycle, a wider scope. Previously the obligation applied to operators of essential services on a two-year cycle. Today it covers all essential entities on a three-year cycle — but the number of entities within the act's reach has grown many times over.

No more exemption via the KRI audit. The provision that allowed a public body to count its internal KRI audit towards the KSC audit has been repealed. A body subject to both regimes now carries out a KRI audit every year and a KSC audit once every three years. These are two different exercises, with different scopes and different requirements as to the auditor.

Independence written directly into the act. An audit may not be performed by anyone who carries out security management tasks within the audited entity, or who carried out such tasks within one year before the audit began. That ends the situation in which the same person implements the controls and assesses how well they work.

Penalties for failing to audit. Failure to perform the audit is expressly listed among the sanctionable breaches. An essential entity faces up to EUR 10 million or 2% of turnover (whichever is higher), and no less than PLN 20,000; an important entity up to EUR 7 million or 1.4% of turnover, and no less than PLN 15,000. A separate penalty may fall on the head of the entity — up to 300% of their remuneration.

The timetable. Entities that met the criteria on 3 April 2026 have until 3 April 2027 to implement the obligations under Chapter 3, and until 3 April 2028 to complete their first audit.

Who may carry out an audit

The KSC Act sets out three permissible routes: an accredited conformity assessment body, a sectoral CSIRT, or at least two auditors meeting one of three alternative qualification conditions.

The first route is a certificate from the list set out in the Regulation of the Minister of Digital Affairs of 12 October 2018 (Journal of Laws 2018 item 1999). The list covers CIA, CISA, CISM, CRISC, CGEIT, CISSP, SSCP, Certified Reliability Professional, the ISA/IEC 62443 Cybersecurity Expert certificates, and lead auditor certificates for information security management systems (ISMS) under PN-EN ISO/IEC 27001 and for business continuity management systems under PN-EN ISO 22301, issued by an accredited personnel certification body.

The second route is documented practice of at least three years in auditing the security of information systems. The third is two years of practice supplemented by a postgraduate diploma in information system security auditing, issued by an institution entitled to confer a doctorate in economics, engineering or law.

Practice is defined concretely: performing at least three audits of information system security or business continuity within the last three years, or performing such audits on at least a half-time basis.

KRI imposes no formal certification requirements on the auditor at all — what counts is independence from the audited area and substantive competence. That is a gap which some bodies fill with an "in-house" audit carried out by the very IT specialist who implemented the controls being assessed. Formally the audit exists; in practice it has no diagnostic value.

Types of security audit

A vulnerability assessment is an automated or semi-automated process of scanning systems and networks for known security vulnerabilities. Tools such as Nessus, Qualys or OpenVAS sweep the infrastructure for out-of-date operating systems, missing security patches, weak configurations and badly configured network services. A vulnerability assessment is fast, repeatable and relatively inexpensive, which is why it should be run regularly — at least once a quarter for critical systems. Its main drawback is that it identifies only known vulnerabilities and takes no account of whether they can be exploited under real conditions, nor of zero-day threats.

Penetration testing

A penetration test (pentest), by contrast, is a simulation of a real attack by authorised specialists, designed to establish how effectively the systems defend themselves. During a pentest the security team attempts to break into the system, escalate privileges, exfiltrate data and cover its tracks — exactly as a real attacker would. A pentest goes considerably further than a vulnerability assessment, because it tests not only technical weaknesses but also procedures, staff awareness and overall operational security. A penetration test should be run at least once a year and, for organisations in critical sectors (finance, infrastructure, healthcare), at least twice a year, particularly after significant infrastructure changes.

Compliance audits

A compliance audit verifies whether the organisation meets the requirements of standards and regulations such as GDPR, ISO 27001, NIS2 or the Polish Banking Law. The auditor assesses processes, policies, documentation and the implementation of required controls. This is not a technical test but a holistic assessment of the organisation's security maturity against legal requirements and industry standards. A compliance audit is mandatory for many organisations and should be carried out at least once a year — and twice a year for large organisations handling sensitive data.

The average cost of a data breach is around PLN 850,000.

A configuration review is a detailed analysis of the settings of systems, network devices, databases and applications, looking for misconfigurations that could pose a security risk. The specialist checks whether servers are configured in line with security benchmarks (CIS Benchmarks, for example), whether services run with the lowest possible privileges, whether logging is set up correctly and whether all unnecessary services are disabled. This form of audit matters especially after new systems are deployed or the architecture changes.

Audit, penetration test, vulnerability scan — three different things

These three terms are often used interchangeably in commercial proposals, yet they denote entirely different kinds of work, different costs and different kinds of evidence.

An audit is — per the definition in ISO 19011 — a systematic, independent and documented process for obtaining evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled. That last phrase is the crucial one: an audit is always measured against some frame of reference — a standard, a regulation, an internal policy. Without criteria there is no audit, only a review.

A vulnerability scan is an automated comparison of the systems and software versions detected against a database of known vulnerabilities. NIST SP 800-115 sets out the limitation of this method explicitly: scanners do not detect vulnerabilities that only emerge from a combination of several factors and, by assigning low risk to each individual finding, can create a false sense of security.

A penetration test is, according to the same NIST publication, testing in which the auditor mimics real attacks in order to find ways around the controls — typically looking for combinations of vulnerabilities that grant greater access than any one of them would on its own. NIST runs it in four phases: planning, discovery, attack and reporting. And it warns: systems may be damaged or taken out of service during the test, so the scope and rules of engagement must be agreed in writing before it begins.

This distinction is not academic — the law reflects it. DORA treats "vulnerability assessments and scans" and "penetration testing" as separate items in the catalogue of required tests, and places TLPT in a separate, higher category.

Audit methodologies

Professional security audits rest on established methodologies. The OWASP Top 10 lists the ten most serious threats to web applications and is the starting point for any application tester. PTES (the Penetration Testing Execution Standard) is a detailed standard describing every phase of penetration testing, from reconnaissance through post-exploitation to reporting. The NIST Cybersecurity Framework, meanwhile, provides a structure for managing cybersecurity risk around five core functions: Identify, Protect, Detect, Respond and Recover. A professional auditor should be familiar with all three approaches and select the methodologies that fit the purpose of the audit and the nature of the organisation.

What auditors actually find — CERT Polska data for 2025

Rather than reaching for a "ten most common mistakes" list, it is worth looking at hard data. The CERT Polska Security Testing Team published, in its 2025 annual report, the distribution of vulnerabilities found in its own audits, classified according to the OWASP Top 10:2025. Web application testing accounted for 72% of the work performed.

The distribution of findings: security misconfiguration — 40%, broken access control — 18%, authentication failures — 12%, cryptographic failures — 10%, insecure design — 9%. The first four categories account for roughly 80% of all the problems found.

The conclusion is an awkward one for tool vendors: the dominant problem is not a lack of technology but the way it has been configured. Default passwords, open administrative ports, security headers left untouched, service accounts with administrator privileges — these are not gaps that another licence will close.

In mobile applications the picture is starker still: attack surface exposure and faulty communication between components were present in 95.1% of the applications tested, application integrity problems in 50%, and insecure network communication in 38.7%.

For scale: in 2025 CERT Polska received 658,320 reports and registered 260,783 incidents — 152% more than the year before. Computer fraud accounted for 97.1% of incidents and phishing for 30% of all events. There were 179 recorded cases of ransomware.

Reporting the results

A security audit report should be a comprehensive document containing an executive summary, a detailed description of the vulnerabilities found, remediation recommendations and a risk assessment. Every vulnerability found should be classified by severity — usually into four categories: critical (requiring immediate action), high (should be fixed within days), medium (remediation can be planned over weeks) and low (worth addressing, but less urgent). Critical vulnerabilities are those that can lead directly to loss of access to systems, theft of data or interruption of operations. High severity means vulnerabilities that an attacker could exploit but that require certain additional conditions or knowledge. Medium severity covers vulnerabilities that can be exploited but demand considerably greater effort. Low severity means theoretical vulnerabilities or those that are difficult to exploit in practice.

Critical vulnerabilities can lead to loss of access to systems.

A well-written report also contains an executive summary — a synopsis for non-technical decision-makers that explains the risk in business language. Instead of saying "an XSS flaw was found in the form", the report should explain: "a vulnerability was found that could allow an attacker to steal the session of a logged-in employee and, as a result, gain access to sensitive client data". That shifts the perspective from technical to commercial and justifies the investment in fixing it.

The report and what follows — procedural obligations

The audit report does not close the matter; since 2026 it starts specific clocks running.

An essential entity submits a copy of the report to the authority competent for cybersecurity within 3 working days of receiving it. The deadline runs from receipt of the report, not from completion of the audit work — worth reflecting in the contract with the auditor, so that the signing date does not catch the organisation mid-holiday season.

The authority may at any time order an essential entity to have an audit carried out by an external party, specifying the deadline and the categories of eligible providers. For an important entity such an order is possible in the event of a significant incident or another breach of the act. The decision is immediately enforceable — there is no time to start looking for a provider from scratch.

For public bodies operating under the KRI regime, the internal audit report is the primary evidence of compliance with §19(2)(14) during an inspection. Inspectors usually ask three things: who carried out the audit and whether they were independent of the area assessed, what the scope was, and what happened to the findings. A report with no remediation plan and no evidence that it was carried out is a document, not proof of compliance.

The remediation plan

A remediation plan is a coordinated strategy for eliminating the vulnerabilities found. Not every vulnerability can be fixed immediately — in reality, improving security is a long-term process. A well-constructed remediation plan prioritises: critical vulnerabilities should be fixed within 1–2 weeks, high ones within a month, medium ones within a quarter and low ones within a year. The plan should be realistic, taking account of the resources available to the organisation and the impact on day-to-day operations.

Audit frequency should match the organisation's risk profile. Small companies with limited infrastructure may run a comprehensive security audit once a year, supplemented by a quarterly vulnerability assessment. Large corporations handling sensitive data, and systems in critical sectors, should run penetration tests at least twice a year and vulnerability assessments monthly. After every major infrastructure change — a cloud migration, the deployment of a new ERP system, a change of service provider — the audit should be repeated. In addition, every security incident should be followed by a detailed audit aimed at establishing the root cause and preventing similar incidents in future.

Red flags in audit reports include very general conclusions with no concrete examples, no information on vulnerability severity, no clear remediation recommendations, or a report suggesting that the auditor did not really test the system and merely ran an automated scanner. A professional auditor should always be able to evidence every vulnerability found, show how it could be exploited and suggest specific ways to fix it. If an auditor cannot do that, their report is worth very little.

The return on investment from regular audits is overwhelming. The cost of a single audit is typically 5 to 20 per cent of the estimated cost of one serious security incident. An organisation investing PLN 50,000 a year in security audits can avoid potential losses running into millions of złoty. Regular audits also make it possible to demonstrate due diligence in a regulatory context — if an incident does occur, being able to show that the organisation tested its security regularly will be decisive in assessing potential regulatory penalties or civil claims.

An IT security audit is an investment, not a cost. It does not only happen to "other companies" — security incidents affect organisations of every size, from small start-ups to large corporations. The only difference is whether the risk was identified and removed before it materialised, or discovered only after the attack. Organisations that have opted for a recurring IT security audit can sleep soundly, knowing they are doing everything in their power to protect their systems, their data and their reputation.

The audit is a starting point, not a destination. The findings have to be translated into lasting mechanisms — how to organise security day to day is covered in Cybersecurity in your company, and the response playbook for an event in Incident management step by step.

What it costs, and why the range is so wide

There is no independent, publicly available study of the security audit market in Poland. Every figure in circulation comes from provider price lists and offer aggregators — and they differ by an order of magnitude. For a web application test, published rates start at around PLN 2,000 net with some providers, while the average from an offer aggregator for the same service is close to PLN 35,000.

That discrepancy is itself informative: the market has no standardised scope. The same name is used to sell both a few hours of automated scanning with a generated report and several weeks of work by a team manually verifying an application's business logic.

Before you compare offers, establish four things: exactly what is in scope (the number of applications, IP addresses and user roles), whether the testing is manual or automated, whether a retest after the fixes are deployed is included in the price, and who signs the report and what qualifications they hold. Without that, you are comparing figures, not services.

To be candid: for compliance audits — KRI, KSC or ISO 27001 — public pricing data barely exists. The cost depends on the number of locations, the complexity of the line-of-business systems and the initial state of the documentation, and a sound quotation can only be prepared once the scope has been established.