Many clients still assume they have completed a penetration test simply because they received a security report with a list of findings. In most cases, what they actually have is a vulnerability scan. At a glance, both approaches look similar. Both produce reports, list issues, and include recommendations. But they do not answer the same question.

A vulnerability scan is designed to identify known technical weaknesses. It looks for outdated software, known CVEs, misconfigurations, and patterns that can be detected automatically. The result is a structured list of findings. That is useful as a baseline, but it does not explain what those findings mean in practice.

A penetration test takes a different approach. It does not stop at identifying weaknesses. It tries to understand what those weaknesses enable. Instead of looking at findings in isolation, it connects them, tests them, and evaluates how far an attacker could realistically go. That difference changes the value of the result entirely. In real scenarios, it is common to see environments where a scan reports no critical issues, yet a penetration test still identifies a viable attack path. Not because there is one severe vulnerability, but because multiple smaller weaknesses can be combined. Consider a situation similar to what we see during testing. A publicly accessible document is found within a web application or exposed directory. The document itself does not contain anything that would trigger a critical alert. There is no exploit, no obvious injection point, and no high severity CVE. From a scanning perspective, this may not appear significant.

From a penetration testing perspective, it becomes a starting point. If the document contains internal server names, environment labels, references to file shares, backup paths, domain naming conventions, or internal URLs, it reveals structure. At that point, the focus shifts from the document itself to what can be derived from it.

If server naming conventions are visible, roles can often be inferred such as domain controllers, application servers, or storage systems. If username formats appear, that can support username enumeration. If internal URLs are exposed, they can guide further discovery of endpoints that were not initially visible. If a document references domain structure or service accounts, it provides insight into authentication models.

From there, testing continues. We look for externally accessible services that follow the same patterns, test authentication flows, and identify additional entry points. What started as a harmless document becomes a pivot point into the environment. A vulnerability scan would not interpret that context. It might list an exposed file, or it might ignore it entirely. It would not build a narrative of how that information could be used. A penetration test does exactly that.

The same applies to findings often labeled as low or medium severity. One endpoint returns too much information, another lacks proper rate limiting, and a third reveals whether a user exists. Individually, these are not critical. Combined, they can enable account compromise or privilege escalation.

This is the key difference. A vulnerability scan answers what might be wrong. A penetration test answers what can actually be done.

And from a business perspective, this is what matters. Management does not make decisions based on CVE lists. They need to understand whether data can be accessed, systems disrupted, or accounts compromised. Without that context, a report remains technical but not actionable.

Vulnerability scanning still has its place. It is useful for maintaining technical hygiene and identifying known issues early. But it cannot replace the depth of a penetration test. Treating scan results as a full assessment often creates a false sense of security while real attack paths remain undiscovered.

If you want to go beyond scan results, an AresISEC penetration test can help uncover the weaknesses that matter in a real world scenario.

Sources:
OWASP – Web Security Testing Guide
NIST – Technical Guide to Information Security Testing and Assessment (SP 800-115)

When organizations begin preparing for NIS2, the first instinct is often to understand the Directive itself. Many teams start by reading legal articles and trying to interpret what each paragraph requires. That approach rarely leads to clarity. NIS2 is not primarily a legal exercise. It is a governance and risk management framework that pushes organizations to understand their exposure, build operational resilience, and ensure that leadership is directly involved in cybersecurity oversight. In practice, companies rarely struggle because they ignore NIS2. They struggle because they approach it in ways that do not reflect how the Directive actually works.

Several patterns appear repeatedly when organizations start their preparation.

1.Treating NIS2 as a documentation exercise

One of the most common mistakes is treating NIS2 as a paperwork project. Policies are written, responsibilities are assigned, and a risk assessment document appears in a shared folder. Once the documentation exists, the organization assumes that the requirement has been fulfilled. The Directive expects something very different. NIS2 focuses on operational security and continuous risk management. Systems evolve, infrastructure changes, suppliers rotate, and threat actors adapt. A document written once cannot reflect a constantly changing environment. Supervisory authorities will not only review whether policies exist. They will expect evidence that security measures are actually implemented and functioning.

2. Staying too abstract

Another common pattern is producing strategic documents that remain disconnected from technical reality. An incident response plan may exist, but the organization has never simulated an incident. A business continuity plan might be approved by management, yet no recovery exercise has been performed. Supplier security policies are defined, but vendors have never been evaluated beyond a questionnaire. NIS2 places emphasis on practical implementation. Controls must exist not only in documentation but also in daily operations. Organizations that remain at policy level often discover gaps when they try to demonstrate how those policies work in practice.

3. Trying to interpret every legal article

Some teams spend weeks trying to interpret the Directive line by line. This usually creates confusion rather than progress. NIS2 describes objectives and responsibilities, but it does not prescribe exact technical configurations or step by step implementation instructions. A more effective starting point is operational visibility. Organizations should first understand their environment. What assets exist. Which services are critical. How systems are interconnected. Which third parties are integrated into their operations. Without this foundation, compliance discussions remain theoretical.

4. Not knowing where to start

Many companies ask the same question: where should preparation actually begin? The answer is rarely tools or policies. It begins with visibility. An organization cannot manage risks in systems it has not identified. It cannot protect suppliers it has not classified. It cannot report incidents it cannot detect. A reliable asset inventory, network mapping, and identification of critical services form the basis for meaningful risk management. Once this visibility exists, security controls and governance structures become much easier to design.

5. Underestimating management responsibility

One of the most significant shifts introduced by NIS2 is executive accountability. Cybersecurity is no longer considered only a technical function. Management bodies must approve cybersecurity risk management measures, oversee their implementation, and ensure that the organization understands its exposure. This requirement changes internal dynamics. Security discussions must move beyond technical terminology and translate cyber risk into business impact. Leadership cannot remain distant from cybersecurity decisions. Governance structures must reflect that responsibility.

6. Overlooking supply chain exposure

Many high profile incidents in recent years originated through compromised suppliers. NIS2 reflects this reality by placing clear emphasis on supply chain security. Organizations are expected to understand the role external providers play in their operations and to evaluate the risks associated with those relationships. This requires more than contractual language. Companies must identify which vendors are critical, how their systems interact with internal infrastructure, and what level of security assurance is required from them. Ignoring supplier risk leaves organizations exposed even when internal controls appear strong.

7. Reporting requirements without detection capability

NIS2 introduces strict timelines for incident reporting. Organizations must provide an early warning within 24 hours of detecting a significant incident, followed by a detailed notification within 72 hours. These timelines assume that detection mechanisms are already functioning. In many environments incidents are discovered weeks after initial compromise. Logging may be incomplete, monitoring fragmented, and escalation procedures unclear. Without operational detection capabilities, reporting obligations cannot be met. NIS2 therefore indirectly pushes organizations to strengthen monitoring and response functions.

8. Looking at NIS2 only through the lens of penalties

Financial penalties associated with the Directive receive significant attention. While the potential fines are substantial, focusing exclusively on them often leads organizations to aim for minimal compliance. A broader perspective reveals that NIS2 can serve as a catalyst for stronger security governance.

Organizations that implement structured risk management often gain better visibility of their infrastructure, clearer accountability structures, stronger incident response capabilities, and improved resilience against disruptions. In that sense the Directive does more than enforce compliance. It encourages maturity. NIS2 does not require organizations to memorize legal text. It requires them to demonstrate that cyber risk is understood, managed, and governed. Supervisory authorities will look for evidence that organizations know their systems, monitor their infrastructure, assess supplier exposure, and involve leadership in security decisions. Companies that treat NIS2 as a documentation exercise will struggle to demonstrate this. Organizations that approach it as a framework for structured cybersecurity governance will be far better prepared, regardless of regulatory pressure.

Sources:

European Union – Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2 Directive)

ENISA – ENISA Threat Landscape 2023

World Economic Forum – Global Risks Report 2024

Penetration testing is often treated as a form of reassurance. The engagement is commissioned, the test is completed, and the final expectation is simple – confirmation that everything is under control. When the report contains no critical findings, the outcome is usually interpreted as success. In real-world environments, however, this conclusion is often misleading.

A clean report does not automatically mean a secure environment. More often, it indicates that the test was limited to areas that were already known, controlled, or considered safe to examine. Real attackers do not respect such boundaries. They look for weak transitions, overlooked assumptions, and places where technical design no longer matches how the organisation actually operates.

That is where penetration testing provides real value, but only when it is allowed to go beyond a formal verification exercise.

Automated tools play an important role in identifying known weaknesses, but their perspective is inherently narrow. They can only detect what has already been defined and categorised. In real penetration tests, serious security issues rarely appear as single, obvious vulnerabilities. They emerge through combinations of minor weaknesses that, taken together, allow meaningful progress through systems and networks.

These paths are not visible in scan results. They require an understanding of system relationships, authentication models, privilege boundaries, and human behaviour. This is where manual testing and attacker-style thinking make the difference.

The true distinction between an average penetration test and a valuable one is not the number of findings, but the clarity of the story those findings tell. A list of technical issues without context does little to support decision-making. A realistic attack scenario, on the other hand, immediately shows which assumptions fail, how far an attacker could move, and where the organisation would struggle to respond.

This is precisely why a “good” result sometimes deserves scepticism. When a test produces no significant findings, the most important question is not what was found, but what was never examined. If critical systems were excluded from scope, if privileged identities were not tested, or if no scenario assumed a compromised user, the report may look reassuring while providing little insight into real resilience.

In practice, penetration testing often reveals not a lack of security controls, but their incomplete or purely formal implementation. Multifactor authentication exists, but not everywhere it matters. Monitoring is in place, but alerts are not acted upon. Rules have been defined, but over time have turned into undocumented exceptions. These issues are rarely exposed through compliance-driven assessments, yet they become obvious when the environment is viewed through an attacker’s lens.

Penetration testing helps bridge the gap between theoretical and actual risk. It shows which weaknesses are truly exploitable, which findings are merely technical observations, and where a real attack would have tangible business impact. This shifts security discussions away from abstract scores and towards scenarios that support informed decisions.

The most valuable outcomes are often uncomfortable. They challenge existing decisions, expose neglected systems, and highlight compromises that were made without a full understanding of their consequences. That discomfort is not a failure of the test. It is evidence that the test is doing its job.

The purpose of penetration testing is not to prove that everything is secure. It is to provide an honest picture of how the organisation would fare under real attack conditions. The most dangerous outcome is not a critical finding, but a report that creates confidence where it is not justified.

Sources:

OWASP – Web Security Testing Guide

NIST – SP 800-115: Technical Guide to Information Security Testing

SANS Institute – Penetration Testing (Glossary)

The period between Christmas and New Year usually brings slower business operations, reduced staffing, and a focus on keeping only essential processes running. For attackers, this is not downtime. It is an opportunity. Security incidents that begin during the holidays are often not detected immediately, and their full impact becomes visible only after normal operations resume.

Experience from real-world incidents shows that holidays are not an exception but one of the most vulnerable periods of the year. Not because of new or advanced threats, but because existing weaknesses combine with reduced oversight and slower response.

Why attackers target the Christmas and New Year period

Attackers choose timing deliberately. The holiday season creates a predictable environment where organizations operate with limited capacity. It is well known when key employees are on leave, when security teams are understaffed, and when decisions are delayed. In these conditions, attackers gain more time inside systems before being noticed. Even basic intrusions can progress further than usual simply because no one is actively watching.

Decision making also slows down. When suspicious activity is detected, escalation is often delayed due to unclear responsibility or unavailable personnel. This allows attackers to move laterally, collect data, and prepare more damaging stages of an attack.

Fewer people, slower response, relaxed controls

During the holidays, security rarely fails by design. It simply loses priority. IT and security teams often work with reduced coverage, and in smaller organizations security monitoring may be limited to occasional checks. Alerts remain unread, logs are collected but not actively reviewed, and suspicious events are not correlated into a meaningful picture.

At the same time, temporary exceptions become normal. Temporary user accounts remain active, remote access is not reviewed, and security controls are loosened to make remote work easier. These decisions increase the attack surface precisely when the ability to respond is at its weakest.

The most common attacks during the holiday period

Attacks at the end of the year are rarely technically sophisticated. Their success depends on timing and human behavior. Phishing remains the most common attack vector. Messages often imitate delivery notifications, holiday greetings, changes to work schedules, or urgent financial requests before year end. Employees working remotely may not have an easy way to verify such requests, increasing the likelihood of error.

Ransomware attacks frequently begin with compromised accounts or phishing emails, but are executed when attackers believe the organization will respond slowly. Every hour of delay during the holidays increases pressure and potential damage.

Compromised VPN and remote access services are also common. Weak passwords, missing multi-factor authentication, and outdated configurations allow attackers to gain silent access. These intrusions often remain undetected until January, when unusual behavior or a major incident finally surfaces.

In most cases, these are not new vulnerabilities. They are known technical weaknesses that existed long before, but become critical when active monitoring is reduced.

What organizations can realistically do without round-the-clock monitoring

Not every organization has the resources for continuous security monitoring or on-call response teams. That does not mean they are defenseless. The first step is understanding real exposure. Without clear visibility into technical vulnerabilities, it is difficult to know which weaknesses actually matter. This is where a vulnerability assessment becomes essential.

A vulnerability assessment provides a structured overview of weaknesses across systems, applications, and network infrastructure. Instead of assumptions, organizations gain a clear picture of technical gaps that can be exploited during periods of reduced attention.

The second step is prioritization. Not all vulnerabilities carry the same risk. Understanding which issues have the greatest potential impact allows teams to focus limited time and resources where it matters most.

The third step is preparation. Organizations that understand their weaknesses can address critical findings before the holidays and enter the period with lower risk and greater control, even without continuous monitoring.

Holidays do not create problems, they expose them

The holiday season does not cause security incidents by itself. It reveals how effective existing controls really are when daily routines and constant oversight disappear. Organizations with a clear understanding of their technical weaknesses and real risk posture enter the holidays with fewer surprises. Those that rely on assumptions often begin the new year responding to incidents that could have been prevented.

Sources:

FBI & CISA – Ransomware Awareness for Holidays and Weekends (AA21-243A)
Palo Alto Networks Unit 42 – Incident Response Report

The NIS2 Directive introduces broader obligations, stricter technical requirements and significantly higher accountability for entities across the EU. It expands the scope of regulated sectors, strengthens supervisory powers and introduces substantial penalties that can reach up to 10 million euros or 2 percent of global annual revenue. With only 24 hours to submit an initial incident notification and the expectation of demonstrated technical controls, it becomes clear that compliance cannot be achieved through documentation alone.

Organizations that postpone their preparation usually struggle not with policies, but with technical weaknesses: missing visibility, misconfigurations, unmanaged vulnerabilities and insufficient monitoring. These issues surface quickly once NIS2 analysis begins.

Insufficient Technical Controls

Article 21 of the Directive outlines mandatory technical and organizational measures such as vulnerability management, data protection, supply chain security, identity and access management, secure configuration, network monitoring and regular validation of controls. In practice, many organizations rely on basic tools such as antivirus, firewalls and MFA while missing essential elements like continuous monitoring, segmentation and comprehensive logging.

Technical debt accumulated over years cannot be compensated with policies alone. NIS2 expects real operational security, not theoretical security on paper.

Incomplete Asset and Data Inventory

A precise asset inventory is crucial for identifying critical systems, understanding dependencies and assessing risk. NIS2 indirectly requires this through Articles 20 and 21. Many organizations lack full visibility into servers, services, legacy systems, Internet-facing endpoints, APIs and key data flows. Undocumented or abandoned systems often remain exposed without monitoring.

Without an accurate map of assets and data, risk assessments become generic and protective measures are implemented in the wrong places or at the wrong priority.

Poorly Configured or Incomplete Logging

NIS2 places strong emphasis on rapid detection, analysis and reporting of incidents. Article 23 requires an initial notification within 24 hours and a more detailed report within 72 hours. This is not possible without comprehensive and synchronized logging.

Common gaps include missing administrative logs, missing application audit trails, lack of logging on backup systems, insufficient SIEM coverage and no time synchronization. When an incident occurs, organizations often discover they do not have the data required to reconstruct the event or support a timely notification.

Lack of Network Segmentation

Flat networks and broad access rights remain common despite the Directive’s expectation of reduced attack surface and restricted lateral movement. In many environments, critical systems, employee workstations and backup environments still share the same segments, making containment almost impossible.

Proper segmentation, micro-segmentation in virtual environments, strict separation of administrative networks and isolation of backups are essential measures that directly support NIS2 expectations.

Weak Incident Response Preparedness

NIS2 requires structured incident response capabilities, including forensic readiness, early threat detection mechanisms, recovery procedures and scenario testing. Many organizations have incident response plans on paper but lack the technical capabilities to execute them.

Frequent issues include the absence of centralized event visibility, missing playbooks, untested backups, no integrity checks and no tooling for rapid forensic collection. When an incident occurs, the organization is unable to respond within the timelines mandated by Article 23.

Occasional Instead of Continuous Vulnerability Management

Vulnerabilities do not follow audit cycles, yet many organizations perform scans only once or twice a year. NIS2 explicitly requires vulnerability management as a continuous process. Without authenticated scanning, post-patch verification and real-time monitoring of emerging vulnerabilities, organizations remain exposed.

Reports often pile up without prioritization, leaving critical findings unresolved for extended periods.

Overemphasis on User Training Instead of Technical Foundations

User awareness is important, but it cannot replace insufficient technical architecture, poor configuration or missing monitoring capabilities. Some organizations invest heavily in training while leaving the core infrastructure unchanged and vulnerable.

If architecture, administration and monitoring are not adequately implemented, even highly aware users cannot prevent system-wide compromise.

NIS2 is not merely another regulatory requirement but also an opportunity to modernize infrastructure, strengthen operational resilience and introduce structure into security processes. Organizations that start early gain clarity, reduce pressure and avoid last-minute remediation. Those that delay often face simultaneous technical and organizational challenges.

If you need a quiet, structured and practical approach to assessing your security posture or planning your next steps, AresISEC can support you throughout the preparation process. NIS2 may be demanding, but it is also a chance to align security with real operational risks.

Sources:
EUR-Lex – NIS2 Directive (EU) 2022/2555
European Commission – NIS2 Directive Overview
ENISA – NIS Investigation and Guidance
ENISA – Security Measures Under NIS2
European Commission – Digital Strategy: Cybersecurity