IT security auditing in 2026: scope, methodology, evidence, and legal requirements

An audit, a security assessment, vulnerability scanning, and penetration testing are not the same thing

These terms are often used as if they meant the same thing, especially in procurement documents and service descriptions. That creates problems because each type of work answers a different question and produces different evidence.

An audit evaluates the subject under review against agreed criteria. A criterion may be a legal provision, a standard, a contract, an internal policy, an approved configuration baseline, or a precisely identified combination of them. An audit includes planning, sampling, evidence collection and evaluation, findings, and formal reporting. It may cover a management system, a process, a service, or a particular information system.

A security assessment often has a more diagnostic purpose. It may examine the design, configuration, resilience, or effectiveness of controls without issuing a formal conformity conclusion. NIST SP 800-53A Rev. 5, including Release 5.2.0 issued on 27 August 2025, provides customizable procedures for assessing security and privacy controls.^[4] It is not, however, a Polish legal requirement.

Vulnerability scanning is used to identify defined classes of known vulnerabilities and configuration weaknesses in a systematic way. A scanner result is not yet an audit finding. The assessor still has to determine whether the issue is actually present, how the system is exposed, whether compensating controls exist, and what the issue means in the organization's context.

A penetration test examines whether agreed attack scenarios can be carried out in practice and what follows from successful exploitation. It requires explicit authorization, rules of engagement, scope, permitted techniques, operating hours, an emergency contact, and a process for handling disruption. NIST SP 800-115 remains a useful guide to technical testing methods and their limitations.^[12]

These forms of assessment can complement one another. An IT security audit may establish that the organization has a vulnerability-management process, while vulnerability scanning can determine whether specific weaknesses are present in the environment under review. A penetration test can demonstrate a practical attack path, but it cannot by itself establish conformity of the entire ISMS. A hardening review can assess configuration against an approved baseline, but it does not replace an assessment of accountability, risk management, business continuity, or incident management.

A certification audit is another category. It is a third-party audit performed by a certification body as part of a certification process. ISO/IEC 27006-1:2024 specifies additional requirements for bodies auditing and certifying ISMSs against ISO/IEC 27001.^[18] An internal audit, an advisory audit, or a consulting report is not a certificate.

Start with the objective, criteria, and scope

A common failure occurs when an organization purchases a "security audit" without defining what is actually to be assessed. A phrase such as "audit against ISO 27001, NIS2, and GDPR" is still not a sufficient scope. ISO/IEC 27001 is a management-system standard, NIS2 is an EU directive, and the GDPR is a regulation governing personal-data processing. Each has a different scope, audience, and method of demonstrating compliance.

The audit initiation document should define at least the objective, criteria, organizational and technical scope, assessment period, exclusions, limitations, sampling method, and rules for access to evidence.

• The objective should describe the decision that the report is expected to support. Examples include assessing conformity with Section 19 KRI, verifying selected KSC obligations, evaluating readiness for ISO/IEC 27001 certification, or assessing the effectiveness of selected controls.
• Criteria should be versioned and unambiguous. If a configuration baseline is being assessed, its version should be named. If the audit concerns law, the applicable act and legal status should be identified. If a standard is used, the exact edition should be specified. Mixing different versions of requirements in one checklist makes the basis of later conclusions difficult to reconstruct.
• The organizational and technical scope should identify the entities, processes, locations, services, systems, suppliers, interfaces, and data included in the assessment. A scope should not stop at an asset list. The auditor needs to understand which business services those assets support and which dependencies may affect the result.
• The assessment period matters particularly for logs, incidents, access reviews, changes, backups, recovery tests, and training. Examining a configuration on one day does not establish that the underlying process worked correctly for the entire year.
• Exclusions and limitations should be stated together with their effect on assurance. If the auditor could not access a cloud environment, could not verify a network configuration, or received only a supplier declaration, the report should say so clearly.

How a sound audit works

ISO 19011:2026, published in May 2026 as the fourth edition, covers auditing principles, audit-program management, conducting audits, and the competence of people involved in the process.^[1] The 2026 edition replaced ISO 19011:2018 and gives greater attention to technology, digitalization, virtual environments, and risk-based thinking.^[1] ISO/IEC 27007:2020 adds guidance for ISMS audits.^[2] Assessment of individual controls can also be supported by ISO/IEC TS 27008:2019, which remains published but is under revision.^[16]

In practice, an audit should contain several connected stages.

1. Planning establishes the criteria, sample, schedule, roles, communication channels, limitations, and risks created by the assessment itself. Active testing requires separate authorization and safety rules.
2. Document review is used to determine how the system is supposed to operate. The purpose is not to count procedures. The auditor should identify the owner of the control, its objective, and the evidence that should be produced during normal operation.
3. Interviews help explain a process, but a statement is not sufficient evidence. If an administrator says that every account belonging to a departing employee is disabled on the same day, the auditor should test a sample of actual departures.
4. Observation shows the process in operation. It may cover incident handling, access provisioning, administrator activity, entry to a server room, or the execution of a recovery test.
5. Sampling is one of the basic mechanisms for controlling audit effort. Samples may consist of user accounts, changes, incidents, devices, suppliers, backups, or privileged permissions. The selection method should match the risk and the audit objective.
6. Technical verification can include reading configuration, querying an identity directory, reviewing cloud policies, examining firewall rules, analyzing logs, or checking endpoint control status. Active tests, vulnerability scans, and penetration tests should have separately defined scopes and authorization.
7. Triangulation means comparing different types of evidence. A policy may require MFA, an administrator may state that it is deployed, while the configuration may show an exception for a technical account. That discrepancy is usually more important than the absence of another document.
8. Factual reconciliation does not mean negotiating the outcome. The audited party should be able to point out a factual error, missing evidence, or a misunderstanding of the architecture. It should not be able to remove a properly supported finding merely because the finding is inconvenient.
9. After the audit, a remediation plan is needed. It should identify the owner, deadline, remediation method, residual risk, and the evidence required to close the finding. Important findings should normally be subject to retesting.

Evidence: what is sufficient and what is merely persuasive

The main difference between a defensible audit and an opinion review is the quality of evidence. Evidence should be appropriate for the conclusion, reproducible where practical, and protected against unauthorized change.

A document can show that the organization established a rule. It does not automatically prove that the rule is followed. A screenshot can show a configuration state, but without a date, system identity, and context it may be difficult to validate. A configuration export or a query result obtained in the auditor's presence will often provide stronger evidence than an image supplied without provenance.

For sensitive evidence, the parties should establish secure transfer, encryption, retention, and deletion of working copies. An auditor should not collect secrets "just in case." Complete databases, private keys, and passwords are usually unnecessary. Controlled exports, read-only sessions, or evidence demonstrated by the system owner are often sufficient.

A sample provides reasonable, not absolute, assurance. If 12 of 900 accounts are examined, the report should not state that all accounts are correct. It should record the size and selection method of the sample, the result, and the limitation on inference. In high-risk areas, the sample can be increased or the entire population can be evaluated with a query or script.

What may fall within an IT security audit

Scope should follow the objective and risk, not a universal service package. In practice, an audit may examine governance, management accountability, risk management, asset inventory, identities and access, infrastructure configuration, cloud security, applications, vulnerabilities, backups, continuity, monitoring, incidents, suppliers, and physical security.

For identity and access management, the full account lifecycle matters: creation, role change, permission assignment, review, privileged access, MFA, technical accounts, and deprovisioning. Merely checking whether "MFA is enabled" may miss exceptions, weak account-recovery methods, or uncontrolled service accounts.

Infrastructure work may cover endpoints, servers, mobile devices, networks, segmentation, administrative services, configuration management, and hardening. CIS Controls v8.1 can help prioritize safeguards, while CIS Benchmarks can provide technical criteria for particular technologies where the organization has adopted them as a baseline.^[13] CIS Controls are not an audit methodology or Polish law.

In cloud environments, the audit should cover not only resources but also tenant organization, identities, roles, keys, logging, policies, network configuration, data copies, and the division of responsibility with the provider. Lack of access to the provider's administrative plane should not be replaced with the assumption that "the cloud is secure by definition."

For application security, OWASP ASVS 5.0.0, released in May 2025 and still the stable release on 29 August 2026, can be used as a set of verifiable technical requirements for web applications and web services.^[14] An application audit may be supplemented by code review, penetration testing, dependency analysis, and review of the software-development process.

For vulnerability management, the audit should examine information sources, scan frequency, result validation, prioritization, remediation deadlines, exception handling, and verification after remediation. Vulnerability risk should not be reduced to a CVSS number.

CVSS 4.0 describes technical vulnerability severity through Base, Threat, Environmental, and Supplemental metric groups.^[15] FIRST explicitly recommends enriching the Base assessment with threat information and local environmental context, while factors such as regulatory obligations, financial loss, number of affected customers, and reputational damage remain outside CVSS.^[15] A CVSS score is therefore an input to risk assessment, not an organizational risk assessment by itself.

For business continuity, the audit should examine not just whether backups exist but also recovery objectives, dependencies, protection of backup copies, separation, testing, and recovery results. RPO describes the target recovery point, or acceptable data loss expressed as time. RTO describes the target time to restore a service. A backup schedule is not automatically evidence that RPO or RTO is being met.

Monitoring and incident management require assessment of log sources, time synchronization, retention, integrity, detection rules, escalation, responsibilities, and evidence from actual cases. In this area, an IT security audit can be supplemented by an assessment of a 24/7 SOC: the important question is not merely whether logs are collected, but whether critical scenarios are visible, someone reviews them, and the organization can actually respond.

How to describe findings and risk

A good finding should allow the reader to understand what was required, what was observed, and why it matters. At minimum, it should identify the criterion, factual condition, evidence, sample scope, likely cause, possible effect, and recommendation.

Conformity and risk should be kept separate. Conformity asks whether a defined requirement is satisfied. Risk concerns the likelihood and consequence of an adverse event in the context of assets, exposure, threats, and existing controls.

A breach of a legal obligation may be formally significant even when the technical probability of harm is low. Conversely, a serious attack path may arise from a combination of several small weaknesses and may not correspond to a single checklist item.

A simple "likelihood x impact" matrix should not be used mechanically unless the organization has defined what the values mean. A risk matrix is useful only if its criteria are repeatable, risk owners understand the scale, and the result leads to a decision.

What the report should contain

An audit report should work for two different audiences: management and the people who will fix the problems. It is therefore often useful to separate an executive summary from technical detail.

The management summary should present the most important risks, obligations, dependencies, and decisions. It should not be a list of ports, IP addresses, and configuration parameter names.

The methodology section should identify the objective, criteria, scope, dates, sampling approach, and limitations. That allows the reader to judge how far the findings can reasonably be generalized.

Each finding should have traceable evidence. A broadly distributed report does not need to contain secrets, full configuration extracts, or personal data. Detailed evidence can be placed in a protected technical annex.

Remediation priority should reflect risk, legal obligations, dependencies, and feasibility. A recommendation such as "deploy MFA" is weak if it does not say which accounts and systems are affected, what exceptions are permitted, and how effectiveness will be verified.

The report should not promise complete security or the absence of future incidents. It describes the condition of a defined scope at a defined time based on defined evidence.

How to choose methodologies and standards

ISO 19011:2026 is a reference for the principles and organization of management-system audits.^[1] It is not a certification standard for the audited organization and does not replace the criterion of the system being examined.

ISO/IEC 27007:2020 concerns ISMS auditing and supplements ISO 19011.^[2] On 29 August 2026, the 2020 edition remains published, but ISO is revising it.

ISO/IEC 27001:2022 with Amd 1:2024 contains requirements for an ISMS and may serve as an audit criterion.^[3] An internal audit against ISO/IEC 27001 is not the same as a certification audit.

ISO/IEC TS 27008:2019 gives guidance for reviewing and assessing the implementation and operation of information security controls, including technical control assessment.^[16] It remains published but is under revision.

NIST SP 800-53A Rev. 5 provides customizable procedures for assessing controls.^[4] It is especially useful where a systematic assessment of the design, implementation, and operation of specific controls is required.

NIST CSF 2.0 organizes cybersecurity risk-management outcomes and can be used to build current-state and target-state profiles.^[5] It is not a certificate or a Polish legal requirement.

Mappings between frameworks can reduce duplicated assessment work, but they do not create automatic equivalence. The same evidence may support several requirements, but each requirement must still be evaluated within its own scope and context.

What KRI actually requires

On 29 August 2026, the Regulation of the Council of Ministers of 21 May 2024 on the National Interoperability Framework remains in force.^[6] ELI states that it will cease to have effect on 23 February 2027.^[6]

Section 19(2)(14) requires entities performing public tasks to ensure a periodic internal information security audit at least once a year.^[6] The legal basis is Section 19, not Section 20. Section 20 concerns accountability and system logs, including mandatory logging of specified activities and, where no separate retention rule applies, a two-year retention period.^[6]

Section 19(3) provides a mechanism under which the requirements of paragraphs 1 and 2 are deemed satisfied where the ISMS is based on PN-ISO/IEC 27001 and where controls, risk management, and auditing are based on Polish Standards related to that standard, including PN-ISO/IEC 27002 and PN-ISO/IEC 27005.^[6] This is not a general obligation to hold an ISO/IEC 27001 certificate.

A replacement KRI regulation is being prepared in 2026 under project RD313.^[17] The project would, among other changes, remove ISMS provisions from the new KRI on the basis that those matters are addressed in KSC. On 29 August 2026, however, RD313 is still a draft and not binding law.^[17] A KRI audit performed in 2026 should therefore use the 2024 regulation that is actually in force.

KSC after implementation of NIS2

The KSC amendment of 23 January 2026 entered into force, in general, on 3 April 2026.^[8] For an audit conducted at the end of August 2026, the current codified text of the Act on the National Cybersecurity System, as maintained by the Chancellery of the Sejm and dated 18 August 2026, should be the primary source.^[7]

Article 15(1) KSC requires an essential entity, at its own expense, to conduct at least once every three years a security audit of the information system used in the process of providing its service. The period is calculated from the date on which the auditors prepare and sign the report of the previous audit.^[7] The essential entity submits an electronic copy of the report to the competent cybersecurity authority within three working days of receiving it.^[7]

The competent cybersecurity authority may order an external audit of an essential entity at any time and of an important entity where a significant incident or another infringement of the Act has occurred.^[7] The regular three-year audit under Article 15(1) is therefore not a general obligation imposed on every important entity.

Article 16 provides that an essential or important entity must meet the obligations in Chapter 3 within 12 months of satisfying the criteria for that status, while an essential entity must ensure its first audit within 24 months of that date.^[7] For entities that already met the relevant criteria when the amendment entered into force, Article 33 of the amending Act provides corresponding 12- and 24-month periods calculated from 3 April 2026.^[8] The transitional provisions contain exceptions, including one for former operators of essential services that had already completed an earlier statutory audit.^[8]

KSC also regulates who may perform the statutory KSC audit. It may be performed by an appropriately accredited conformity-assessment body, by at least two auditors satisfying the statutory conditions, or by the relevant sectoral CSIRT where its auditors meet those conditions.^[7] Article 15(2a) excludes a person who performs tasks under Articles 8 and 9-13 in the audited entity or performed those tasks there during the year preceding the start of the audit.^[7] This is a specific legal restriction, not merely a general principle of impartiality.

NIS2 should be treated as the EU regulatory background and the source of the supervisory model. Article 32 requires competent authorities to have powers over essential entities that include on-site inspections, off-site supervision, regular targeted security audits, ad hoc audits, and security scans.^[9] A Polish entity should nevertheless determine its concrete obligations primarily from the current KSC.

GDPR: regular effectiveness evaluation, not necessarily "one audit per year"

The GDPR does not impose a general requirement to conduct an IT security audit once a year. Article 32(1)(d) requires, as appropriate to risk, a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of processing.^[10]

An audit can form part of that process, but it is not the only possible method. Depending on risk, appropriate assurance may require configuration reviews, recovery tests, vulnerability scans, penetration testing, incident exercises, supplier assessment, and other forms of verification.

A GDPR audit should also distinguish security from complete compliance with the Regulation. A technical test may provide evidence relevant to Article 32, but it cannot by itself assess legal bases for processing, transparency obligations, retention, data-subject rights, or international transfers.

DORA and its relationship with KSC

DORA has applied since 17 January 2025 to the financial entities identified in the Regulation.^[11] For financial entities other than microenterprises, the ICT risk-management framework is regularly subject to internal audit in accordance with the entity's audit plan, and the frequency and focus of ICT audits must be proportionate to ICT risk.^[11]

DORA also establishes advanced threat-led penetration testing. The requirement to conduct TLPT at least every three years applies to entities identified under Article 26, not to every entity subject to DORA.^[11] TLPT is not a synonym for an ISMS audit or for an ordinary penetration test.

The relationship between DORA and KSC requires particular care. Article 8i KSC provides that, for essential or important entities in the banking and financial-market-infrastructure sectors, certain KSC provisions concerning the ISMS and significant-incident reporting do not apply, subject to an expressly listed set of exceptions.^[7] Article 15 is not among those exceptions. It is therefore unsafe to assume mechanically that a DORA-covered financial entity must also perform the periodic Article 15 KSC audit merely because it meets the criteria for an essential or important entity. Its exact sectoral status and the operation of Article 8i have to be checked first.

Remote, on-site, or hybrid auditing

There is no credible universal formula such as "70% of an audit can be done remotely." The method should follow the evidence that is required and the risks involved.

Documents, configuration exports, logs, many interviews, and a substantial part of cloud configuration can often be assessed remotely. On-site work may be necessary for physical safeguards, isolated environments, OT, media storage, observation of real operational processes, or cases where remote evidence does not provide sufficient assurance.

ISO 19011:2026 addresses changes caused by technology, digitalization, and virtual environments and places greater emphasis on risk-based thinking.^[1] It does not prescribe a percentage split between remote and on-site work or a single correct audit format.

Remote work should use approved channels, named accounts, minimum necessary privileges, and appropriate access logging. Where evidence can be demonstrated in a controlled session, copying an entire database or configuration set into the auditor's environment is often unnecessary.

Independence, competence, and confidentiality

Impartiality does not mean that an auditor can never have worked for the organization before. The actual conflict has to be assessed: who designed the control, who implemented it, who operates it, who approves the finding, and whether compensation depends on the audit outcome.

For an ordinary advisory audit, independence follows from the chosen methodology, contract, and expected level of assurance. For the statutory KSC audit, additional legal conditions apply under Article 15, including qualification requirements and the one-year exclusion for people performing tasks under Articles 8 and 9-13 in the audited entity.^[7]

Before contracting an audit, it is worth examining the team's experience in the relevant sector and technologies, its sampling method, report-review process, evidence-protection procedures, and ability to perform retesting. A personal certification can demonstrate a defined body of knowledge, but it does not replace experience or eliminate a conflict of interest.

Confidentiality is critical because audit documentation can become a ready-made map of organizational weaknesses. Reports, configuration exports, scan results, and working papers should have defined classification, recipients, processing location, retention, and secure deletion procedures.

How to close a finding

Closing a finding should not mean changing a cell from "open" to "closed." There should be evidence that the cause was addressed or that the residual risk was accepted at the appropriate decision-making level.

If the finding concerns missing MFA, evidence may include configuration, the list of affected accounts, and a test result. If it concerns a vulnerability, a rescan or retest may be needed. If it concerns unclear responsibility, closure requires more than a document: the role has to be assigned and the process put into operation.

Retesting should be proportionate to the finding. The entire audit does not always need to be repeated. For a critical problem, however, it may be appropriate to check not only the fix itself but also whether the remediation introduced new risk.