ESKA Security Blog

Many companies invest heavily in protecting their own infrastructure. They deploy firewalls, endpoint protection, multi-factor authentication, backup systems, and security monitoring. Internal systems become increasingly difficult to compromise. So attackers change their strategy. Instead of attacking the organization directly, they target someone the organization already trusts. A software vendor. A cloud service provider. An IT outsourcing company. A managed service provide

One conversation plays out in almost every company when it's time to discuss the cybersecurity budget. The CISO or IT Director walks into a meeting with a list of security initiatives, software, and services the organization needs. The CEO or CFO looks at the numbers and asks: "Why do we need all of this? Nothing has happened to us." The security team starts talking about threats, vulnerabilities, and attack vectors. Management hears technical terminology but struggles to con

When a company begins thinking seriously about cybersecurity, one question usually comes up: “Fine, we bring in a vCISO. But what exactly will change in the way the business operates?” Most descriptions of the role sound too abstract. They talk about strategy, risk management, governance, and security process development. These concepts are important, but business leaders usually want something more practical: specific actions, visible progress, and measurable outcomes. That

When a security incident occurs, the first instinct in most organizations is to restore operations as quickly as possible. Rebuild the affected systems, reset credentials, patch the vulnerability, and move on. It is an understandable response, downtime is expensive and pressure from leadership is immediate. It is also one of the most damaging decisions a security team can make. Restoring systems before conducting a forensic investigation destroys evidence. Without that eviden

A few years ago, security questionnaires were something large enterprises sent to enterprise vendors. Today, they land in the inboxes of mid-sized companies, startups, and regional service providers with increasing regularity and the stakes attached to them have changed significantly.

Annual penetration testing made sense in a different era. Infrastructure changed slowly. Applications had quarterly release cycles at best. The attack surface was mostly on-premises and well-defined. Running a pentest once a year gave organizations a reasonable snapshot of their security posture because that posture did not change dramatically between tests.

Before an attacker touches a single system, they search. They search Google, LinkedIn, GitHub, breach databases, and DNS records. They look through job postings, conference talks, and developer forums. They build a detailed picture of your infrastructure, your technology stack, your employees, and your security gaps, using nothing but publicly available information and tools that anyone can access for free.

A vulnerability scan came back with no critical findings. The team breathed a sigh of relief, marked the task complete, and moved on. Three months later, an attacker was inside the network.

Your team runs on SaaS. Sales lives in Salesforce. Finance works out of Xero. Everyone communicates through Slack or Microsoft Teams. Documents flow through Google Workspace or SharePoint. Onboarding, HR, payroll, project management: all cloud, all SaaS, all connected. Attackers know this. And they have adjusted accordingly. The assumption that SaaS is secure by default because someone else is running the infrastructure is one of the most expensive mistakes a company can make

Getting ISO 27001 certified is hard work. Months of gap analysis, risk assessments, policy writing, internal audits, and a two-stage external audit that feels like it examines everything. When it is over and the certificate arrives, the relief is real. That relief is also dangerous. The organizations that struggle most with ISO 27001 are not the ones that fail to get certified. They are the ones that treat certification as a destination rather than a starting point, and then

Phishing still matters — and it remains one of the most common entry points for attackers. But in 2026, it is no longer the only or even always the most reliable path to compromise. Increasingly, attackers are just as likely to succeed by exploiting unpatched systems or abusing trusted third-party access as they are by sending a convincing phishing email.

ISO describes ISO/IEC 42001 as the first global standard for AI management systems and states that it provides requirements and guidance for organizations that develop, provide, or use AI systems.

If you operate in the financial sector in Europe or work with EU-based clients, you’ve likely heard about DORA (Digital Operational Resilience Act). The Digital Operational Resilience Act (DORA) is a regulatory framework introduced by the European Union to fundamentally strengthen how financial organizations manage technology risks and ensure business continuity in the digital era.

The difference is simple in theory but very important in practice. SOC 2 Type I looks at whether your controls are properly designed and in place as of a specific date. SOC 2 Type II goes further and evaluates whether those controls operated effectively over a defined period of time.

The “classic” phishing email with broken English is no longer the baseline. Attackers now use generative AI to produce believable messages at scale, adapt in real time, and expand beyond email into voice calls, chat apps, QR codes, and OAuth consent prompts.

As cyber threats grow more sophisticated and regulatory pressure increases, many companies realize they need strategic security leadership—but not necessarily a full-time, in-house CISO. This is where a vCISO (Virtual Chief Information Security Officer) becomes a practical and cost-effective solution.

Penetration testing should reduce risk—not introduce outages, broken releases, or noisy incidents that steal engineering time. The difference between a “smooth pentest” and a “pentest fire drill” is rarely the tester’s skill; it’s usually pre-engagement preparation: clear scope, safe test conditions, and operational guardrails.