ESKA Security Blog

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.

Secure SDLC, or Secure Software Development Lifecycle, is not another formal framework added on top of development. It is a practical approach where security is built into the product from the very beginning, not added at the end before release.

Cloud infrastructure penetration testing for Amazon Web Services (AWS) or Microsoft Azure is a controlled security assessment that evaluates the real resilience of your cloud environment from an attacker’s perspective — strictly within an agreed scope and rules of engagement.

An Incident Response Plan (IRP), also called a cybersecurity incident response plan or security incident response plan, is a documented and agreed approach that defines how an organization responds to a security incident from the first warning signal to full recovery and post-incident improvements.

API penetration testing is no longer a niche security service. For companies, especially SaaS, fintech, e-commerce, and healthcare businesses — API security has become a core business risk factor.

Most cloud breaches are not caused by “advanced hacking.” They happen because cloud services make it easy to ship fast, and one risky setting can quietly turn an internal asset into a public one. Cloud is also highly dynamic: teams deploy new services weekly, permissions evolve, and infrastructure becomes code.

Offensive security can be one of the highest ROI investments in cybersecurity, but only if the method matches the goal. Many companies “buy a pentest” when they actually need an end-to-end red teaming exercise, or they launch a bug bounty before they have the internal capacity to triage and fix incoming reports. The result is predictable: wasted effort, frustrated engineers, and a report that does not change risk.

A penetration test report usually fails for one of three reasons. Engineers cannot reproduce the issue reliably, so it never gets prioritized. Leadership cannot see business impact, so remediation does not get funded. Security teams cannot translate findings into tickets and verification steps, so the work stalls.

Risk control mapping is a core practice in governance, risk and compliance. It connects business risks with internal controls and with evidence that these controls actually operate. Many organisations call the final artefact a risk control matrix. This matrix becomes a central document for audit readiness and for managing internal controls.