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