The IT security audit in 2026: scope, methodology and legal requirements

An audit, an assessment, a scan and a pentest are not the same thing

In procurement these terms are often used interchangeably, although they lead to different evidence and different conclusions:

• An audit assesses conformity with agreed criteria: a legal provision, a standard, a contract or an internal regulation. It covers a plan, the selection of a sample, the gathering of evidence, findings and a formal report. It may address a management system, a process or a specific information system.
• A security assessment usually has a broader or more diagnostic purpose. It may examine the design of safeguards and their effectiveness without issuing a formal conformity opinion. NIST SP 800-53A supplies configurable control assessment procedures, but it is not in itself a Polish legal obligation.^[4]
• A vulnerability scan detects known vulnerabilities and configuration errors. A scanner's output has to be verified, its exposure established and its significance for the organisation assessed.
• A penetration test checks whether agreed attack scenarios can be carried out in practice. It requires rules of engagement, the system owner's consent and a plan for what happens if something is disrupted. NIST SP 800-115 sets out the strengths and limits of testing techniques.^[11]
• A certification audit is a particular kind of third-party audit conducted by an accredited certification body. Neither an internal audit nor a consultant's report is a certificate.

One form of examination does not automatically substitute for another. An audit may show that the organisation has a vulnerability management process, but only a scan or a technical test will produce evidence about specific vulnerabilities. A penetration test may demonstrate an attack path, yet on its own it will not confirm the conformity of an entire management system.

Purpose, criteria and scope come first

A good project begins with a short initiating document. It should set out:

• the purpose: for example assessing conformity with § 19 of the KRI regulation, readiness for an ISO/IEC 27001 audit, or the effectiveness of selected safeguards;
• the criteria: the precise instruments, contractual provisions, policies, versions of standards and approved configuration baselines;
• the organisational and technical scope: entities, processes, sites, systems, suppliers, interfaces and data;
• the period under review: which matters for log review, incidents, changes, entitlements and restore tests;
• exclusions and limitations: with reasons, and with their effect on the reliability of the conclusions;
• rules for access to evidence: read-only permissions, the channel for transferring files, retention, encryption and the deletion of working copies.

"An audit of conformity with ISO 27001, NIS2 and the GDPR" is not yet a scope. Each of those instruments has a different character, different addressees and a different way of demonstrating conformity. The first step is to establish which requirements actually apply to the organisation.

How a sound audit proceeds

ISO 19011:2026 sets out the principles of auditing management systems, the management of an audit programme, the conduct of an audit and auditor competence.^[1] ISO/IEC 27007:2020 extends that guidance to audits of an information security management system.^[2] In practice the process should cover:

1. planning: the risk of the examination itself, the criteria, the sample, the schedule, roles and communication rules;
2. documentation review: not in order to count procedures, but to establish the intended way of working and the owners of the controls;
3. interviews and observation: a conversation indicates how a process is meant to work, but a statement alone is not sufficient evidence;
4. examination of a sample: for instance user accounts, changes, backups, incidents, devices and supplier contracts;
5. technical verification: reading configurations, querying systems, reviewing logs and, under separate authorisation, active testing;
6. triangulation: comparing the document, the state of the system and what people actually do. A discrepancy is often more telling than a missing document;
7. agreeing the facts and reporting: the auditee may correct a factual error, but should not be negotiating the removal of a properly documented finding;
8. post-audit activity: a remediation plan, risk acceptance and re-testing of the most important findings.

A sample gives reasonable, not absolute, assurance. The report should state its size and how it was selected. If 12 accounts out of 900 were examined, it is not permissible to write that "all accounts are correct"; what can be described is the result for the sample and the limits on what may be inferred from it.

What can fall within the scope of an IT security audit

Scope is matched to the purpose and the risk. The full list is not a compulsory package for every project, but the following are typically considered:

• security governance, management accountability, risk and metrics;
• asset inventory, ownership, information classification and data flows;
• identities, the account lifecycle, privileged access, MFA and segregation of duties;
• workstations, servers, mobile devices, networks, segmentation and remote administration;
• cloud and SaaS services, tenant configuration, keys, logging and the division of responsibility with the provider;
• secure development and maintenance of applications; OWASP ASVS 5.0.0 can serve as a set of verifiable requirements for web applications.^[13]
• management of vulnerabilities, updates, configuration and exceptions to the baseline;
• backups, restore testing, business continuity and dependencies on infrastructure;
• monitoring, logs, detection, and incident handling and reporting;
• suppliers, the supply chain, contractual terms, the right to audit and service exit;
• physical and environmental security, where it matters for the system under examination.

CIS Controls v8.1 helps set priorities among safeguards, and CIS Benchmarks help assess the configuration of specific technologies. Neither, however, is interchangeable with an audit methodology or with a legal provision.^[12]

How to describe findings and risk

Every significant finding should contain at least: the criterion, the facts, the evidence, the sample covered, the cause, the possible consequence and a recommendation. A remediation plan additionally needs an owner, a deadline and a way of confirming completion.

Two axes should not be conflated:

• conformity: whether a requirement is met, partly met or not met;
• risk: the likelihood, the business consequence, the exposure and the safeguards already in place.

A breach of an obligation may be formally significant even where the technical risk is low. Conversely, a serious attack path may not correspond to any single "nonconformity" on a checklist. CVSS 4.0 describes the technical severity of a vulnerability; FIRST explicitly leaves financial, regulatory and reputational consequences outside the base score. A CVSS number is therefore not an assessment of the organisation's risk.^[14]

What the report should contain

• an executive summary: the main risks, decisions and dependencies, without technical overload;
• purpose, criteria, scope, dates and methods: so that another competent reader understands the basis of the conclusions;
• limitations: missing evidence, exclusions, systems that were unavailable, and the effect of all this on the level of assurance;
• findings with traceable evidence: without disclosing secrets in the part intended for a wider readership;
• remediation priorities: reflecting risk, legal obligation, dependencies and feasibility;
• a separate technical annex: where detailed addresses, configurations or evidence would increase the risk of disclosure;
• a re-verification plan: stating what evidence will close each finding.

A report should not promise "full security" or guarantee the absence of an incident. It describes a state at a given time and within a given scope, on the basis of the evidence available.

Choosing methodologies and criteria

• ISO 19011:2026: general guidance on auditing management systems; it replaced the 2018 edition.^[1]
• ISO/IEC 27007:2020: guidance on the programme and conduct of ISMS audits and on auditor competence.^[2]
• ISO/IEC 27001:2022: requirements for an ISMS; it can serve as an audit criterion. An organisation may implement the standard without certifying.^[3]
• NIST SP 800-53A Rev. 5: assessment procedures for security and privacy controls, adaptable to the purpose and the risk tolerance.^[4]
• NIST CSF 2.0: organises the expected outcomes of cybersecurity management and lends itself well to current and target profiles; it is not itself a certification.^[5]

Mapping between methodologies helps avoid repeating work, but it does not demonstrate automatic conformity. One control may partly support several requirements, and those requirements may differ in whom they bind and what evidence they call for.

What KRI, KSC/NIS2, the GDPR and DORA actually require

KRI. The regulation of 21 May 2024 requires entities performing public tasks to ensure a periodic internal information security audit at least once a year. The basis is § 19(2)(14), not § 20; § 20 now deals with accountability and system logs. § 19(3) names the Polish PN-ISO/IEC standards of the 27000 family as one way of treating the requirements as met. It does not create a general obligation to certify.^[6]

The KSC act after the NIS2 transposition. The amending act entered into force on 3 April 2026. The amended article 15(1) requires an essential entity to audit the security of the information system used to provide the service at least once every three years. The first audit falls, as a rule, within 24 months of meeting the criteria; entities that met them on the day the act entered into force have 24 months from that date. The authority may order an external audit of an essential entity at any time, and of an important entity after a significant incident or another breach of the act. An essential entity submits the report to the competent authority electronically within three working days of receiving it.^[7] NIS2 gives supervisory authorities the power to conduct regular and targeted audits of essential entities, but the directive itself does not introduce a universal "annual audit" for every organisation.^[8]

GDPR. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures, where appropriate. The GDPR sets no single frequency and does not name an audit as the only permissible form. The testing plan should follow from risk, the nature of the data and changes in the processing.^[10]

DORA. The regulation has applied since 17 January 2025. For financial entities other than microenterprises, the ICT risk management framework is subject to regular internal audit in accordance with the audit plan, with the frequency and scope matching the ICT risk. The requirement for TLPT at least once every three years applies only to entities designated by the competent authorities under article 26, not to every entity within the scope of DORA.^[9]

These obligations can overlap. An annual KRI audit does not automatically discharge the statutory KSC audit, and a TLPT is not a synonym for an ISMS audit. A compliance assurance programme has to state which piece of evidence covers which requirement.

Remote, on site or hybrid

There is no credible universal split such as "70 per cent remote, 30 per cent on site". The form of the examination is matched to the evidence and the risk. Documents, configuration exports, logs and interviews can often be assessed remotely. A visit may be necessary for physical safeguards, the work of staff, isolated OT environments, media storage, or wherever remote evidence does not give sufficient assurance.

That distinction has a basis in the methodology. The fourth edition of ISO 19011, published in May 2026 and replacing the 2018 edition, expands precisely the guidance on remote methods, virtual locations and a risk-based approach ^[1]. The standard remains a guidance document rather than a requirements document: nobody is certified against it and it imposes no single form of examination. What matters is whether the chosen method gathers evidence sufficient for the conclusion being drawn.

Remote work should use an approved channel, named accounts with minimal privileges, access logging and an agreed retention period for materials. Handing an auditor complete databases, keys or passwords is usually unnecessary. Controlled exports, read-only sessions and evidence presented by the system owner are better.

Independence, competence and confidentiality

An auditor should be impartial towards the area under examination, but that does not automatically bar every prior engagement. A conflict is assessed on the specifics: who designed the safeguard, who operates it, who approves the findings, and whether the fee depends on the outcome. Statutory audits may carry additional conditions. Under the KSC act, a person who performs, or performed in the previous year, the tasks listed in articles 8 and 9-13 within the entity under examination may not carry out the article 15 audit.^[7]

Before signing, it is worth checking experience in the sector and the technology concerned, the method of sampling, the quality review applied to reports and the procedures for protecting evidence. A personal certificate may confirm a defined body of knowledge, but it substitutes neither for experience nor for an assessment of conflicts of interest.